I think most complains about JDO in this group is not saying that JDO has issues. It just that GAE is so different then traditional environments that old frameworks aren't 100% suitable. If there's a modify version of JDO that strip out irrelevant features, and put in some important low level api features, it will be much much better.
I believe the users who are writing there own frameworks are doing exactly that, from the ground. On Oct 23, 1:19 am, datanucleus <andy_jeffer...@yahoo.com> wrote: > > 1. Without detaching, when you update a field, and later on close the > > PM, the object will be committed regardless. This makes no sense in > > GAE as 99.99% of time you want to control what you commit or not. > > Worse yet if you persist other object and have a transaction, it might > > fail because the objects are in different entity group. > > Which is why there are transactions in JDO, and the use of rollback(). > How GAE/J want to make use of these is down to them, but this is not a > limitation of JDO. > > > 2. To get around #1, you might want to detachCopy the object once it's > > fetched, so that it won't be accidentally committed. However, when the > > object have a child object (or fields that's not in default fetch > > group), detach won't work (when you get child will throw error). You > > need to first get that child, detach it, then use the child as is. > > It's very messy when detaching a object with different types of > > children. > > Which is why there are fetch groups in JDO and fetch depth so you, the > user, has full control over what gets detached. You can detach > whatever you need. > > > 3. Putting object (that has children) in memcache is even more > > annoying. You can't just put it in memcache, because when it's read, > > you can't get the child. I am not sure if I get the child first then I > > will be able to read it later. I just couldn't make it work. > > JDO supports Level2 Cache. This is turned off by default but you could > enable it, to use the memcached feature of GAE/J. This will mean > objects are put into the L2 cache for you, and taken out when you need > them. > > > If you change a type of a field, say from Long to Double, you can > > never delete the entries with JDO. You need to fetch the object first, > > then delete it, but you can't fetch it because a ClassCast exception > > will happen. I end up writing low level keys only query and using low > > level API to delete the entities with keys. > > This is again not a limitation of JDO. You get the same issue with > RDBMS; you have to migrate your schema. Google could provide a schema > upgrade facility to take an existing schema definition and migrate to > the updated form. > > > I can go on but I am tired. :) > > I'm tired too ;-) --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
