My goal wasn't to economise on api _ms so I haven't done any comparisons. afaik, commit is done at an entity level, so I don't monitor individual fields for changes. If I'm wrong then it wouldn't be too difficult to build dirty flags into my DTO setters.
My advice to anybody building apps for GAE is to have your own abstraction layer between JDO/JPA/LLAPI so any porting between regimes is painless. This is why I took the approach of modelling my data in an RDBMS and then generating my object data model automatically. At first it sounds like a retrograde step, but the benefit is that my data model is independent of any specific persistence framework (and the design tools are more mature). On Thu, Oct 22, 2009 at 11:37 PM, Peter Liu <tinyee...@gmail.com> 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 -~----------~----~----~----~------~----~------~--~---
