> There is absolutely nothing in the JDO ***API*** that is irrelevant to > GAE/J and BigTable.
I disagree, and that's the main reason why we developed our own framework. These are just some random thoughts about this subject: * Transactions in JDO is a global thing tied to the persistence store (one database = one transaction), but for GAE it's one transaction per entity group. It's perfectly reasonable to execute two transactions at the same time, which is hard to fit into the traditional development model with spring. * The current way of generating a primary key with a parent is not natural IMHO. My key attribute already has a parent, why should I add _another_ attribute with the parent PK? * Entity retrieval can be done just by providing the primary key, but JDO and JPA are not prepared for it - you must provide the entity class as well. This is redundant. * There are a lot of use cases (structures etc) supported by datanucleus that can be optimized out. This is important in a system where I pay per CPU cycle. The list goes on. The point is that you cannot develop a standard framework that works fine with a RDBMS and expect it to be the optimal solution for a storage that is entirely different. For me, there are enough differences that justify going for a specific solution. My .02 euro. P.S.: Please keep in mind that I have absolutely nothing against datanucleus, which is indeed a nice implementation. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google App Engine for Java" group. To post to this group, send email to google-appengine-java@googlegroups.com To unsubscribe from this group, send email to google-appengine-java+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/google-appengine-java?hl=en -~----------~----~----~----~------~----~------~--~---
