> 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 -~----------~----~----~----~------~----~------~--~---
