JDO vs JPA para Java en Google App Engine

google-app-engine

Question

Deseo desarrollar mi proyecto en Google App Engine con Struts2. Para la base de datos tengo dos opciones, JPA y JDO. ¿Podrían por favor sugerirme en eso? Ambos son nuevos para mí y necesito aprenderlos. Así que me concentraré en uno después de sus respuestas.

Gracias.

Answer 1

¡Ninguno!

Usa Objectify porque es más económico (usa menos recursos) y es más rápido. FYI: http://paulonjava.blogspot.mx/2010/12/tuning-google-appengine.html

Objectify es una API de acceso a datos de Java diseñada específicamente para el almacén de datos de Google App Engine. Ocupa un "terreno intermedio"; más fácil de usar y más transparente que JDO o JPA, pero significativamente más conveniente que la API de bajo nivel. Objectify está diseñado para hacer que los novatos sean inmediatamente productivos y también para exponer todo el poder del almacén de datos de GAE.

Objectify le permite persistir, recuperar, eliminar y consultar sus propios objetos escritos.

@Entity
class Car {
    @Id String vin; // Can be Long, long, or String
    String color;
}

ofy().save().entity(new Car("123123", "red")).now();
Car c = ofy().load().type(Car.class).id("123123").now();
ofy().delete().entity(c);

Answer 2

Acabo de ver esta comparación entre JPA y JDO por DataNucleus mismos: - http://www.datanucleus.org/products/accessplatform_2_1/jdo_jpa_faq.html Una revelación.

Answer 3

El grupo GAE / J google tiene varias publicaciones sobre esto mismo. Haría una búsqueda allí y miraría las opiniones de las personas. Recibirá un mensaje muy diferente a las opiniones expresadas anteriormente. También concéntrese en el hecho de que BigTable no es un RDBMS. Usa la herramienta adecuada para el trabajo

Answer 4

En la carrera entre JDO vs JPA, solo puedo estar de acuerdo con los carteles de datanucleus.

En primer lugar, y lo más importante, los carteles de datanucleus saben lo que están haciendo. Después de todo, están desarrollando una biblioteca persistente y están familiarizados con modelos de datos distintos a los relacionales, por ejemplo Big Table. Estoy seguro de que si un desarrollador de hibernación estuviera aquí, diría: "todas nuestras suposiciones al construir nuestras bibliotecas centrales están estrechamente relacionadas con el modelo relacional, la hibernación no está optimizada para GAE".

En segundo lugar, JPA es, sin duda, de uso más generalizado, ser parte de la pila oficial de Java EE ayuda un poco, pero eso no significa necesariamente que sea mejor. De hecho, JDO, si lees al respecto, corresponde a un nivel de abstracción más alto que JPA. JPA está estrechamente relacionado con el modelo de datos RDBMS.

Desde el punto de vista de la programación, el uso de las API de JDO es una opción mucho mejor, porque conceptualmente comprometes mucho menos. Puede cambiar, teóricamente, a cualquier modelo de datos que desee, siempre que el proveedor que utilice admita la base de datos subyacente. (En la práctica, raramente logra un alto nivel de transparencia, porque se encontrará configurando sus claves principales en el objeto de GAE y se vinculará a un proveedor de base de datos específico, por ejemplo, google). sin embargo, aún será más fácil migrar.

En tercer lugar, puede usar Hibernate, Eclipse Link e incluso saltar con GAE. Google parece haber hecho un gran esfuerzo para permitirte usar los marcos en los que estás acostumbrado a construir tus aplicaciones. Pero lo que las personas se dan cuenta cuando construyen sus aplicaciones GAE como si estuvieran ejecutando en RDBMS es que son lentas. La primavera en GAE es LENTA. Puede buscar en Google Google IO videos sobre este tema para ver si es cierto.

Además, adherirme a los estándares es algo muy sensato que hacer, en principio lo aplaudo. Por otro lado, JPA es parte de la pila Java EE y hace que las personas, a veces, pierdan su noción de opciones. Tenga en cuenta, si lo desea, que Java Server Faces también forma parte de la pila Java EE. Y es una solución increíblemente ordenada para el desarrollo de la GUI web. Pero al final, ¿por qué las personas, las personas más inteligentes, si se me permite decirlo, se desvían de este estándar y usan GWT?

En todo esto, debo decir que hay una cosa muy significativa para JPA. Ese es Guice y su conveniente soporte para JPA. Parece que Google no fue tan inteligente como de costumbre en este punto y está contento, por ahora, de no apoyar a JDO. Todavía creo que pueden permitírselo, y eventualmente Guice engullirá a JDO también, ... o tal vez no.

Answer 5

GAE / J está programado para agregar MYSQL antes de fin de año.

Answer 6

Ir JDO. Incluso si no tienes experiencia en eso, no es difícil elegir, ¡y tendrás una nueva habilidad en tu haber!

Answer 7

JPA es el camino a seguir, ya que parece ser empujado como una API estandarizada y recientemente ha cobrado impulso en EJB3.0. JDO parece haber perdido el impulso.

Answer 8

JPA es el estándar de Sun para la persistencia, JDO está muriendo en mi humilde opinión (en realidad, está muerto pero todavía en movimiento). En otras palabras, JPA parece ser una mejor inversión a largo plazo. Así que supongo que elegiría JPA si ambos fueran nuevos para mí.

Answer 9

La gente que afirma que JDO está muerto no carece de fundamento. Esto es lo que leí en el libro Pro EJB 3 Java Persistence API: "Poco después Sun anunció que JDO se reduciría al modo de mantenimiento de especificación y que la API de Java Persistence obtendría tanto de JDO como de otros proveedores de persistencia y se convertiría en el único compatible estándar en el futuro. ". El autor Mike Keith es el líder de la co-especificación en EJB3. Por supuesto, él es un gran defensor de JPA, pero dudo que sea tan parcial como para mentir.

Es cierto que cuando se publicó el libro, la mayoría de los principales proveedores se unieron detrás de JPA en lugar de JDO, a pesar de que JDO tiene características técnicas más avanzadas que JPA. No es sorprendente porque los grandes jugadores en el mundo EE como IBM / Oracle también son grandes proveedores de RDBMS. Más clientes están utilizando RDMBS que no RDMBS en sus proyectos. JDO estaba muriendo hasta que GAE le dio un gran impulso. Tiene sentido porque el almacén de datos GAE no es una base de datos relacional. Algunas funciones de JPA no funcionan con bigtable, como las consultas de agregación, las consultas de unión, las relaciones propiedad de muchos a muchos. Por cierto, GAE es compatible con JDO 2.3, mientras que solo es compatible con JPA 1.0. Recomendaré JDO si GAE es su plataforma de nube objetivo.

Answer 10

Para el registro, es Google App Engine (GAE), así que jugamos con las reglas de Google no con las reglas de Oracle / Sun.

Debajo, JPA no es adecuado para GAE, es inestable y no funciona como se esperaba. Ni Google está dispuesto a admitirlo, pero sí lo mínimo.

Y por otra parte, JDO es bastante estable en GAE y está (en cierta medida) bien documentado por Google.

Sin embargo, Google no recomienda ninguno de ellos.

http://code.google.com/appengine/docs/java/datastore/overview.html

La API de bajo nivel brindará el mejor rendimiento y GAE tiene que ver con el rendimiento.

http://gaejava.appspot.com/

Por ejemplo, agregue 10 entidad

Python: 68ms

JDO: 378ms

Nativo de Java: 30ms

Answer 11

Soy un usuario feliz de JDO. Sigan con el buen trabajo chicos.

Answer 12

Lo que creo que es terrible sobre el uso de JDO en el momento de escribir esto es que el único proveedor de implementación es Datanucleus y los inconvenientes de eso es la falta de competencia que conduce a numerosos problemas, como:

1. Una documentación no muy detallada sobre algunos aspectos, como extensions
2. Usualmente recibes respuestas sarcásticas de los autores como (¿Has revisado los registros? Puede haber alguna razón para tenerlos) y respuestas molestas como esa.
3. No obtiene una respuesta a su pregunta en un tiempo útil, a veces si obtiene una respuesta en menos de 7 días, debe considerar que es afortunado, incluso aquí en

Siempre estoy esperando que alguien empiece a implementar la especificación JDO sí mismo. Puede ser que ofrezcan algo más y esperemos más atención gratuita a la comunidad y no siempre se molesten en que se les pague el sustento, sin decir que a los autores de Datanucleus solo les importa soporte comercial, pero solo digo.

Personalmente, considero que los autores de Datanucleus no tienen obligación alguna con Datanucleus ni con su comunidad. Pueden abandonar todo el proyecto en cualquier momento y nadie puede juzgarlos por ello, es su esfuerzo y su propiedad. Pero debes saber en lo que te estás metiendo. Verá, cuando uno de nosotros, los desarrolladores, buscamos un marco para usar, no puede castigar ni controlar al autor del marco, pero, por otro lado, ¡necesita terminar su trabajo! Si tuviera tiempo para escribir ese marco, ¿por qué buscaría uno en primer lugar?

Por otro lado, JDO tiene algunas complicaciones como el ciclo de vida de los objetos y cosas que no son muy intuitivas y comunes (creo).

Editar: Ahora sé que JPA también impone el mecanismo del ciclo de vida del objeto, por lo que parece inevitable tratar con los estados del ciclo de vida de las entidades persistentes si desea utilizar una API ORM estándar (es decir, JPA o JDO )

Lo que más me gusta de JDO es la capacidad de trabajar con CUALQUIER sistema de gestión de bases de datos sin un esfuerzo considerable.