I didn't use Spring, but I found detach/attach annoying and irrelevant in GAE context because:
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. 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. 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. 4. When serialized (happens when you memcache put), the size is actually bigger then necessary because some datastore connection related information is also serialized. I don't remember exactly, but a minimal JDO object is like ~500byte. If I serialize its fields with Hessian it's ~50 bytes. Probably not a issue when your object is big. The object I want to cache is some Session info, which is very small, but there might be lots of them. Also, if you really want to cache a JDO object as is, try to make it transient first, it will be smaller. Overall I just feel like detach/attach create more problems then its worth. I just can't think of a scenario that the JDO states are actually beneficial within a GAE context. Here's what I just found out with JDO today: 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. I can go on but I am tired. :) On Oct 22, 7:21 pm, Rusty Wright <rwright.li...@gmail.com> wrote: > Peter, it was gratifying to hear you say "detach/attach is also problematic > when dealing with caching and transactions" because I've been banging my head > against the wall trying to write integration tests with GAE's datastore, > using JDO and Spring's transactions. > > I either get the "is managed by a different Object Manager" error or my > objects don't get persisted or other errors I can't remember now. I can't > figure out if I'm getting bit by Spring, GAE's datastore, or JDO, and it's > very frustrating. > > What has been your experience, war stories, etc.? > > > > Peter Liu wrote: > > Awesome! > > > I recently played with the lower level API as well. Some of the > > features are not available in JDO, like reserving a key before > > committing a new object. The detach/attach is also problematic when > > dealing with caching and transaction. I also noticed small JDO objects > > are much bigger than it needs to be when serialized. > > > Just wondering do you have any performance profiling stats? I also > > feel like JDO is overkill, but I couldn't justify porting all JDO > > objects to another simple type without knowing how much cpu_ms it will > > save. > > > Also, do you keep track of which field is dirty and avoid committing > > unmodified fields? I believe this is important to minimize api_cpu to > > avoid unnecessary index updates. > > > On Oct 22, 2:37 am, Nacho Coloma <icol...@gmail.com> wrote: > >> Hi all, > > >> We have been developing a persistence framework for the AppEngine > >> Datastore based on the raw DatastoreService API. For our (simple) > >> persistence case, both JDO and JPA were a bit overkill as we were > >> spending a significant amount of time jumping through hoops to make > >> our application roll, but at the same time the Datastore API was a too > >> low-level solution to be usable. > > >> So we reinvented our wheel. In two days. > > >> SimpleDS is a light wrapper around the DatastoreService APIs that > >> provide a simple interface for java persistent classes. It does not > >> include fancy stuff or any super features, it's just the > >> DatastoreService ported to a world where Java entities can be > >> persisted directly (using a subset of JPA annotations). This is _not_ > >> a JPA/JDO replacement, and will never be. But we have been using it > >> for some weeks and are quite happy with it. > > >> Any kind of feedback from the AppEngine community would be welcome. > >> Before calling the typical "but we already have JPA/JDO!" argument, > >> please notice the following: > > >> * There are lots of considerations in a relational database that do > >> not apply to AppEngine. This allows a specific solution to be > >> simplified big time. Just see the depth of your typical stack trace to > >> understand what I am talking about. > >> * Solutions can be designed for specific cases that are common > >> practice in AppEngine but do not apply to a relational database. See, > >> for example, saving entities with a parent instance. > >> * Transactions also behave a bit differently, where a "one size fits > >> all" approach would probably not be the best solution. > > >> To better ilustrate with an example, these are some typical tasks > >> performed with SimpleDS: > > >> Retrieve instance: > >> FooBar bar = entityManager.get(key); > > >> Transform from Google Datastore Entity to java and viceversa: > >> Entity entity = entityManager.datastoreToJava(bar); > > >> Save generating a primary key, with a parent instance: > >> FooBar bar = new FooBar(); > >> entityManager.put(parentKey, bar); > > >> More can be seen here:http://code.google.com/p/simpleds/wiki/SimpleTasks > > >> Any discussion about the current API state is welcome. This entire > >> thing was rolled in two days and tested in a couple of weeks so there > >> should be some bugs in between. > > >> It is important to keep in mind the current list of limitations: > > >> * Only the Key class is a supported primary key. > >> * IN and != are not supported (yet). I have big concerns about > >> supporting this, performance-wise. > >> * Relationships are not supported. You can use Keys and collections of > >> Keys for that purpose. > >> * Transactions are not yet included. We are not yet sure about how to > >> proceed here. > > >> As I said, this is not conceived to become a feature-complete JPA > >> replacement, so please don't treat it like that. > > >> Best regards, > > >> Nacho. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
