JDO vs JPA para Java en Google App Engine

El grupo de Google GAE/J tiene varias publicaciones sobre esto mismo. Haría una búsqueda allí y miraría las opiniones de la gente. Obtendrá un mensaje muy diferente a las opiniones expresadas anteriormente. También enfóquese en el hecho de que BigTable no es un RDBMS. Utilice la herramienta adecuada para el trabajo

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.

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

Las personas que afirman que JDO está muerto no carecen de mérito. 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 Java Persistence API se basaría tanto en JDO como en los otros proveedores de persistencia y se convertiría en el único estándar compatible en el futuro.". El autor Mike Keith es el líder de co-especificación en EJB3. Por supuesto que es un gran partidario de JPA, pero dudo que sea parcial suficiente para mentir.

Es cierto que cuando se publicó el libro, la mayoría de los principales proveedores estaban unidos 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 de 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 GAE data store no es una base de datos relacional. Algunas características de JPA no funciona con bigtable, como consultas de agregación, consultas de unión, relaciones de propiedad de muchos a muchos. POR cierto, GAE soporta JDO 2.3 mientras que solo soporta JPA 1.0. Recomendaré JDO si GAE es su plataforma de nube objetivo.

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

Bajo él, JPA no es adecuado para GAE, es inestable y no funciona como se esperaba. Ni Google está dispuesto a apoyarlo, sino 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

API de bajo nivel dará el mejor rendimiento y GAE es todo acerca de rendimiento.

Http://gaejava.appspot.com/

Por ejemplo, añadir 10 entidad

Python: 68ms

JDO: 378ms

Nativo de Java: 30ms

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

En primer lugar, y también 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 de los relacionales, por ejemplo, Big Table. Estoy seguro de que id un desarrollador para hibernate estaban aquí, habría dicho: "todas nuestras suposiciones al construir nuestras bibliotecas centrales están estrechamente acopladas al modelo relacional, hibernate es no optimizado para GAE".

En segundo lugar, JPA está incuestionablemente en un uso más extendido, 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 más alto de abstracción que JPA. JPA está estrechamente acoplado al modelo de datos RDBMS.

Desde el punto de vista de la programación, usar las API de JDO es una opción mucho mejor, porque está comprometiendo conceptualmente mucho menos. Puedes cambie, teóricamente, a cualquier modelo de datos de su deseo, siempre que el proveedor que utilice admita la base de datos subyacente. (En la práctica, rara vez se logra un nivel tan alto 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, seguirá siendo más fácil migrar.

En tercer lugar, puedes usar Hibernar, Eclipse Link e incluso spring con GAE. Google parece haber hecho un gran esfuerzo para permitirle usar los frameworks en los que está acostumbrado a crear sus aplicaciones. Pero lo que la gente se da cuenta cuando construyen sus aplicaciones GAE como si se estuvieran ejecutando en RDBMS es que son lentas. La primavera en GAE es LENTA. Puede google Google IO videos sobre este tema para ver que es cierto.

Además, la adhesión a las normas es una buena cosa sensata que hacer, en principio aplaudo. Por otro lado, JPA ser parte de la pila de Java EE hace que la gente, a veces, perder su noción de opcion. Tenga en cuenta, si se quiere, que Java Server Faces también es parte de la pila de Java EE. Y es una solución increíblemente ordenada para el desarrollo de GUI web. Pero al final, ¿por qué la gente, la gente más inteligente si se me permite decirlo, se desvía de este estándar y usa GWT en su lugar?

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

Go JDO. Incluso si usted no tiene experiencia en ella, no es difícil de recoger, y usted tendrá una nueva habilidad en su haber!

Lo que creo que es terrible de usar 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. Normalmente recibes respuestas sarcásticas de los autores como (¿Has revisado los registros ? Puede haber una razón para tenerlos) y respuestas molestas como esa
3. Usted no obtenga una respuesta a su pregunta en una cantidad de tiempo útil, a veces si obtiene una respuesta en menos de 7 días, debe considerar su propia suerte, incluso aquí en StackOverflow

Siempre estoy esperando que alguien comience a implementar la especificación JDO por sí mismo, puede ser que ofrezca algo más y esperemos que más atención gratuita a la comunidad y no siempre se moleste en recibir un pago por soporte, sin decir que Datanucleus los autores solo se preocupan por apoyo, pero sólo estoy diciendo.

Personalmente considero que Datanucleus los autores no tienen obligación alguna de Datanucleus sí mismo ni de su comunidad. Pueden abandonar todo el proyecto en cualquier momento y nadie puede juzgarlos por ello, es su esfuerzo y su propia propiedad. Pero deberías saber en lo que te estás metiendo. Verás, cuando uno de nosotros los desarrolladores buscan un framework para usar, no puedes castigar o ordenar al autor del framework, pero por otro lado, ¡necesitas hacer tu trabajo ! Si tuvieras tiempo para escribe ese marco, ¿por qué buscarías 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 también JPA impone el mecanismo de ciclo de vida del objeto, por lo que parece que es inevitable tratar con los estados de ciclo de vida de entidades persistentes si desea usar una API standard estándar (es decir, JPA o JDO)

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

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

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

Tampoco!

Use Objectify, porque es más barato (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 Java diseñada específicamente para Google App Engine datastore. Ocupa un "término medio"; más fácil de uso 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 novicios inmediatamente productivo, pero también exponer todo el poder de la GAE datastore.

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);