JDO vs JPA para Java en Google App Engine


81

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

Gracias.

Respuestas:


32

JPA es el estándar de Sun para la persistencia, JDO está muriendo en mi humilde opinión (en realidad, está muerto pero aún 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í.


52
JDO no se está muriendo y está dirigido a una audiencia diferente. Por favor verifique sus datos. JDO ha tenido JDO 2.1, JDO 2.2 y ahora JDO 2.3. JDO es independiente del almacén de datos. JPA está dirigido únicamente a RDBMS. Hecho
DataNucleus

17
Bueno, no creo que podamos decir que la adopción de JDO sea un éxito, no importa cuántas versiones haya. Abre los ojos, JDO podría tener miles de millones de versiones, nadie lo está usando de todos modos (y por favor, no me digas que JDO renacerá gracias a GAE). Entonces, si JPA está dirigido únicamente a RDBMS, explíqueme por qué podemos usar esta API con BigTable de Google. Gracias.
Pascal Thivent

10
Chicos, si Google lo eligió, entonces no se está muriendo. Saben lo que hacen. Por cierto, felicidades @DataNucleus. He visto que eligen su implementación.
santiagobasulto

6
Esta es una mala respuesta. JPA es específico de rdbms. Por lo tanto, no se puede utilizar con la proliferación masiva de almacenes de datos alternativos (los llamados NoSQL) que hemos visto en los últimos años. Al menos sin hacer feos compromisos. Por lo tanto, no marque "JPA is daed" como la respuesta correcta
smartnut007

2
Nunca se deben elegir opciones basadas en la popularidad. ¡Toda la plataforma GAE se basa en una mesa grande y para eso está JDO!
FUD

33

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


3
¿Por qué Google App Engine admite JPA para su almacén de datos BigTable con el complemento datanucleus-appengine (citando datanucleus.org/products/accessplatform/appengine/support.html ) si es un error total? ¿Puedes dar más detalles sobre esto?
Pascal Thivent

16
El soporte de JPA en almacenes de datos que no son RDBMS implica comprometer la API y el lenguaje de consulta. Muchas cosas no encajan, por lo que no son compatibles, ya que son específicas de RDBMS (partes importantes de JPQL, por ejemplo, o muchas anotaciones de JPA, etc.). En consecuencia, no puede tener una portabilidad total entre los almacenes de datos, por lo que cualquier argumento para usar JPA en BigTable como una copia directa de lo que usaría para una tienda RDBMS es falso.
DataNucleus

6
Para JDO, por otro lado, el lenguaje de consulta (JDOQL) no tiene componentes específicos de RDBMS, y los metadatos son neutrales a la base de datos en general con componentes específicos de RDBMS separados limpiamente. En consecuencia, tiene portabilidad entre almacenes de datos. La API de JDO permite el uso de un lenguaje de consulta nativo para cada almacén de datos cuando sea necesario.
DataNucleus

9
Nunca dije que puedes usar la API de JPA completa pero, para mí, esto no evitará que reutilices tu conocimiento de JPA, por lo que no es una razón válida para no usar JPA. Y, por cierto, la portabilidad entre los almacenes de datos no ocurre en la vida real .
Pascal Thivent

4
No va a estar de acuerdo con lo que diga, por lo que no tiene sentido la discusión, ni es necesario escribir en negrita. Sí, la portabilidad entre los almacenes de datos ocurre ya que tengo clientes que hacen precisamente eso. Como siempre, las personas deben decidir las cosas por sí mismas en función de las necesidades de su proyecto, que es lo que decimos en los documentos de DataNucleus. --Andy (DataNucleus)
DataNucleus

24

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


3
Este manifiesto de Datanucleus parece ser muy pro-JDO. Todas sus declaraciones parecen críticas con JPA y defensivas de JDO y, sin embargo, encuentro que usar JPA es una actividad más feliz que usar JDO.
Bendito Geek

8
DataNucleus es compatible con JDO y JPA, y en realidad solo incluimos la mayor parte de JPA2 en DN 2.0. Promovemos ambos, a diferencia de todas las demás soluciones de persistencia, y dejamos que los usuarios elijan. Si cree que existen errores fácticos en cualquier cobertura de JDO o JPA, agradeceríamos sus comentarios. Si forma parte de una agenda política en su nombre, es mejor que se guarde sus sentimientos
DataNucleus

16

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


2
Soy un usuario feliz de JDO: me queda bien una vez que me acostumbre. Además, con JDO tengo la opción de alejarme de GAE / J y Google BigTable sin rediseñar por completo mi intercambio de datos persistente.
Ian Marshall

12

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 API de Java Persistence se basaría tanto en JDO como en los otros proveedores de persistencia y se convertiría en el único soporte compatible estándar en el futuro ". El autor Mike Keith es el líder de co-especificación en EJB3. Por supuesto, es un gran partidario de JPA, pero dudo que sea lo suficientemente 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, aunque JDO tiene características técnicas más avanzadas que JPA. No es sorprendente porque los grandes actores en el mundo de EE, como IBM / Oracle, también son grandes proveedores de RDBMS. Más clientes utilizan 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 características de JPA no funcionan con bigtable, como consultas de agregación, consultas de unión, relaciones de propiedad de varios a varios. 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 de destino.


11

Para el registro, es Google App Engine (GAE), por lo 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. Tampoco Google está dispuesto a apoyarlo, pero es 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 se trata de rendimiento.

http://gaejava.appspot.com/

Por ejemplo, agregue 10 entidades

Python: 68 ms

JDO: 378 ms

Nativo de Java: 30 ms


Ese no es el tipo de resultados que obtengo cuando ejecuto tus pruebas.
código511788465541441

9

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 del relacional, por ejemplo, Big Table. Estoy seguro de que si un desarrollador para hibernate estuviera aquí, diría: "todas nuestras suposiciones al construir nuestras bibliotecas centrales están estrechamente acopladas al modelo relacional, hibernate no está optimizado 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 sobre él, 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 conceptualmente está comprometiendo mucho menos. Teóricamente, puede cambiar a cualquier modelo de datos que desee, siempre que el proveedor que utilice sea compatible con la base de datos subyacente. (En la práctica, rara vez logra un nivel tan alto de transparencia, porque se encontrará configurando sus claves primarias 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 Spring con GAE. Google parece haber hecho un gran esfuerzo para permitirle utilizar los marcos en los que está acostumbrado a crear sus aplicaciones. Pero lo que la gente se da cuenta cuando crea sus aplicaciones GAE como si se ejecutaran en RDBMS es que son lentas. La primavera en GAE es LENTA. Puede buscar en Google videos de IO de Google sobre este tema para ver que es cierto.

Además, adherirse a las normas es algo muy sensato, en principio lo aplaudo. Por otro lado, el hecho de que JPA sea parte de la pila Java EE hace que la gente, a veces, pierda la 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 GUI web. Pero al final, ¿por qué la gente, las personas más inteligentes si puedo decirlo, se desvían de este estándar y usan GWT en su lugar?

En todo esto, tengo que decir que hay algo muy importante 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, por ahora, de no ser compatible con JDO. Sigo pensando que pueden permitírselo, y eventualmente Guice también engullirá a JDO ... o tal vez no.


6

Vaya JDO. Incluso si no tienes experiencia en él, no es difícil de aprender, ¡y tendrás una nueva habilidad en tu haber!


6

Lo que creo que es terrible de usar JDOen el momento de escribir esto es que el único proveedor de implementación es Datanucleusy 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. Por lo general, recibe respuestas sarcásticas de los autores como (¿Ha revisado los registros? Puede que haya una razón para tenerlos) y respuestas molestas como esa.
  3. No obtiene una respuesta a su pregunta en un período de tiempo útil, a veces, si obtiene una respuesta en menos de 7 días, debe considerarse afortunado, incluso aquí en StackOverflow

Siempre espero que alguien comience a implementar la JDOespecificación por sí mismo, tal vez entonces ofrezcan algo más y, con suerte, más atención gratuita a la comunidad y no siempre se preocupen por que se les pague por el apoyo, sin decir que los Datanucleusautores solo se preocupan por el apoyo comercial. , pero solo digo.

Personalmente considero que los Datanucleusautores no tienen obligación alguna con ellos Datanucleusmismos 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 busca un marco para usar, no puede castigar ni ordenar al autor del marco, pero por otro lado, ¡necesita que su trabajo esté listo! Si tuvieras tiempo para escribir ese marco, ¿por qué buscarías uno en primer lugar?

Por otro lado, en JDOsí mismo 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 JPAaplica 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, JPAo JDO)

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


Tienes razón en casi todas las observaciones. ORM es un dolor de cabeza para algunos objetos persistentes complejos (¡meses de depuración, literalmente!). Actualmente estoy atascado con DN 2.1 porque se cambió una propiedad y mi código no funcionará con versiones más nuevas. Dicho esto, DN con JDO es el camino a seguir, en mi opinión.
marcolopes

3

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


2
¿Tiene una fuente para esto?
Taylor Leese

1
Votado en contra porque no creo que esto sea cierto, no puedo encontrar ninguna información en línea que lo respalde y no hay evidencia proporcionada con la publicación.
Steve Armstrong

3
La hoja de ruta menciona que una base de datos SQL con todas las funciones está en proceso code.google.com/appengine/business/roadmap.html
Ashwin Prabhu

Es curioso, pero ahora (31-08-2011) descubrimos que no era cierto en absoluto.
magallanes

1
¿No es verdad? La URL de la vista previa de SQL (beta) de App Engine de Google es bastante larga, así que la he abreviado goo.gl/AhsxX (pensé que era necesario explicarlo en caso de que no sea creyente).
Big Rich

1

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


1

¡Ninguno!

Usa 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 de Java diseñada específicamente para el almacén de datos de Google App Engine. Ocupa un "término medio"; 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 principiantes sean productivos de inmediato y, al mismo tiempo, exponer toda la potencia del almacén de datos GAE.

Objectify le permite conservar, 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);

¿Es esto solo para el almacén de datos? ¿Qué tal Cloud SQL?
Timeless

1
Y la desventaja es que se atan estrechamente al proveedor. No siempre es un problema, pero el objetivo de JDO es evitarlo. (hablando como el que probablemente lo usará para pequeños servicios).
Pijusn
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.