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

Reply via email to