Datanucleus best practices SQL and no SQL databases

Http://www.datanucleus.org/products/accessplatform/features.html

Http://www.datanucleus.org/project/usage.html

JDO vs JPA

One of the main reasons for choosing DataNucleus in particle is that it is really the only full-featured (and free open source) JDO implementation available. but why wocould we want to use JDO over JPA? The following questions, excerpted from

Http://www.datanucleus.org/products/datanucleus/persistence_api.html, are a good concise guide to arriving at this answer.

• Target datastore: JDO is designed for all datastores, whereas JPA is just designed around RDBMS and explicitly uses rdbms/SQL terminology. if using RDBMS then you have the choice. if using, for example, a nosql store then JDO makes much
  More Sense
• Datastore interoperability: Are you likely to change your datastore type at some point in the future? If so you likely ought to use JDO due to its design
• API: Both APIs are very similar. JDO provides more options and control though for basic persistence and retrieval there are differences only in the namings
• ORM: JDO has a more complete ORM definition, as shown on
  Apache jdo orm Guide
• Experience: Do your developers know a special API already? As mentioned the API's themselves are very similar, though the metadata definition is different. Remember that you can use JPA metadata with the jdo api, and vice-versa.
• Querying: Do you need a flexible query language that is object-oriented and extensible? Jdoql provides this and the implementation in datanucleus allows extensions. If you just want SQL then you can use JDO or JPA since both provide this
• Fetch Control: Do you need full control of what is fetched, and when? JDO provides fetch groups, whereas JPA doesn't. Use JDO if this is an important factor for your design

There is a further technical comparison available
Http://db.apache.org/jdo/jdo_v_jpa.html. arguably, neither of these comparisons is objective, the latter, since it sets out to prove that JDO has more features than JPA (and more is not necessarily better ). however, it is clear from both
That JDO provides certain features where JPA does not that pertain specifically to our design
(As listed in the previous sections of this document ).

Other frameworks evaluated

• Hibernate (JPA)-2 full prototypes
  • Very heavy compared to the benefit attached ed.
  • Only works for RDBMS solutions, so separate implementations are required for Mongo and SQL repository layers
  • We definitely learned not to use Spring-Hibernate, as it gives the developer little control over transaction management and persistence logic.
  • Hibernate had a lot of gotchas in terms of cascading persistence operations, lazy loading, and scope of persisted objects
  • Once properly configured, Hibernate worked well for switching between SQL data stores as advertised.
  • POJOs require a relatively high amount of explicit annotation to map to relational schemas
• Datanucleus (JPA)-research only (no prototype)
  • DataNucleus also provides a JPA implementation. The guidelines provided
    Http://www.datanucleus.org/products/datanucleus/persistence_api.html point to JDO being the specification of choice for this project. Thus, having already built prototypes using Hibernate JPA, it was not necessary to further release e JPA in DataNucleus.
• Native Java Mongo driver-1 full prototype
  • Only works for Mongo. This wocould be one option for accessing a Mongo data store if Hibernate/JPA was selected.
  • Developer must subclass the generic DBObject, which is essential just a key/value map, in order to manipulate statements ents as domain objects.
  • Values are obtained and modified using get and put with the specific field names used in the collection. nothing inherently wrong with this handle t that it introduces a lot of room for error that wouldn't be caught by the database (since Mongo does not
    Perform any sort of type or schema checking ).
• Morphia-partial prototype
  • Only works for Mongo. This wocould be an alternative option for accessing a Mongo data store if Hibernate/JPA was selected.
  • Has an advantage over the native Java Mongo driver from a code writing perspective in that the DBObject inheritance and explicit putting/getting are hidden.
  • Ultimately Morphia classes are still just a wrapper around a basic key/value map, requiring an extra layer of translation between an initially simple JSON document and a more complex (but arguably more readable) domain object.
  • Requires an extra layer (some might argue an extra layer of redundancy) to convert objects between documents and domain objects.