It is indeed JDO! - yet again making EJB 3.0/JPA look somewhat limited.OK Steve - I'll take the bait!Can you list the technical advantages that JDO 2.0 has over the draft specification for EJB 3.0/JPA?PJ MurrayCodeFutures Software
Yes, I can.
What I view as the technical advantages are:
1. Less restrictions on the use of Collection. In EJB 3.0/JPA Collections have to contain Entities. In JDO 2.0 they can also contain non-mutable Objects such as Strings, Integers, Dates etc.
2. Less restrictions in POJOs. EJB 3.0 persistence imposes quite a few restrictions and requirements. In EJB3, the author of the class must supply an identity field; the class must not be final; it must not have any final methods; and it must have a no-arguments constructor which cannot be private. JDO 2.0 imposes far fewer restrictions and requirements. Classes must have a no-args constructor, but it can be private. There is no need for an identity field. This means that is is far easier in JDO 2.0 to apply persistence to legacy classes which can't be amended.
3. Less control over retrieval - there is no equivalent in JPA of JDO 2.0 fetch groups - simply lazy/eager fetching. I realise that this in particular is a highly debated topic, but many developers like me prefer the use of fetch groups over explict statements of what is to be retrieved in queries.
4. EJB 3.0/JPA has a primary focus on relational stores, just at the time when new approaches to persistence (such as LINQ) are widening the idea of what type of data can be queried and how. JDO 2.0 works fine on relational stores, but has a far wider focus.
5. Fewer lifecycle states - no equivalent of 'hollow' in EJB 3.0/JPA. This again has been hotly debated. My view is that the range of lifecycle states in JDO assists with reducing the memory requirements for very large transactions. Of course, some will argue that ORM is not appropriate for such 'batch processing'. I prefer not to mix technologies where possible, so I would like to be able to stick to the use of ORM, no matter how large the volume of data.
Obviously, individual implementations of JPA may well do far more than this, and not have such restrictions. However I am talking about specifications here, not products.
Of course, if I am wrong about these technical matters, I would be keen to know.