Hi Jeff, thanks for the insightful points. I am the SimpleDS author,
and thought that maybe some of these issues need further explanation:
> * Not enough use of generics. Key, Query, and PreparedQuery should
> all be generified classes.
We tried that at first, but there is little benefit from that. We
settled for the use of generics for the find() method signatures,
which is what Google collections does, and that seems enough for our
use cases.
> * Key should not be used as the id for a class. The class itself
> identifies the Kind, so having a Key id carries redundant information
> that can be incorrect and cause problems. This becomes really obvious
> when you generify the key class:
>
> [...]
>
> Having an id field instead of a key makes queries easier. With
> Objectify, you can create a query without needing to know that the id
> is part of a key field:
>
> query.filter("id >", 5000).sort("-id")
This would only work with root entities, which are a minority. The
most common case is like this:
> class MyEntity {
> @Id Long id;
> @Parent OKey<ParentEntity> owner;
>
> }
This _is_ redundant since internally GAE stores the owner inside the
Key field. So we settled for the simplest solution, that was to make
visible the Key system used by GAE. It also makes getting by primary
key more efficient, since you don't have to pass the class.
> * I don't like the way SimpleDS (or thelowlevelAPI) makes you pass
> around a Transaction object. By maintaining the transaction within an
> instance of the Objectify/EntityManager/whatever interface, we can
> eliminate all the API method duplication.
I don't like it either, but GAE allows to have several transactions
open at the same time, affecting different shards. We wanted to
support that.
The way JDO circumvents this is by using several PersistenceManager
instances, but that seems weird to me.
> * Classpath scanning shouldn't be required. I wrote a bit about this
> here:http://code.google.com/p/objectify-appengine/wiki/BestPractices#Autom....
> The short version: Each and every library that does classpath
> scanning adds 3-5s to your cold start time. Users see cold start
> time, even on a busy app. It adds up.
We are not requiring classpath scanning. Actually, we have testcases
that just add the persistent classes using
PersistenceMetadataRepository.add() methods. OTOH, in our application
the persistence metadata is read in 1-2 seconds (using minor
optimizations like using classpath: instead of classpath*:), so we
decided it was not worth to remove it.
> * I don't use (or like) Spring.
It is not required anyway. You can initialize SimpleDS using pure Java
(actually, we are doing that too). We only use Spring to do the
classpath scanning, since it has a really efficient implementation for
that.
> All that said, SimpleDS does some things that Objectify doesn't (like
> provide a query language and an IndexManager) so you might like it
> better. It just wasn't for me.
Objectify also has some things that we don't, like better support for
GWT and caching, which is a work in progress in SimpleDS. Make your
pick :)
--
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-j...@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.
