On Tue, Mar 9, 2010 at 8:47 PM, John Patterson <[email protected]> wrote:
> For the sake of comparison, see below for the Twig equivalent
>
> class UserSkill {
> �...@parent User user;
> String skill
> int ability;
> }
>
> Note that no key is required and user is referenced directly so your model
> has no dependency on the low-level datastore
...and instead must make two fetches every time you load a UserSkill
object. Is it at least smart enough to do all the parent fetching as
a single batch get? Does a put() on an entity cascade to its parent?
Claiming that "Twig is the only datastore interface to support...Plain
old Java object data models with no datastore dependencies" is really
too much. All that you can honestly say is that Twig lets you avoid
datastore dependencies...except when you can't. The same can be said
for JDO or Objectify.
Can you avoid a Key reference if you don't want to perform two fetches
for every single load of a parented object?
Can you avoid a Key reference if you don't want to eager-load a
collection of entities?
Can you avoid a Key reference if you have a one-to-many relationship
where the many-side might have 5001 values?
If you really want to avoid Key objects, you'll probably get a lot
farther with DataNucleus' support for collection proxies. But I doubt
either will let you build efficient real-world applications completely
without relying on a few Key references.
Incidentally, you can generally avoid Key references using Objectify
if you so choose. Keys only become mandatory when you are dealing
with parented entities -- which should be used infrequently for
performance reasons. There's no reason you can't just use simple ids
as foreign key references.
> Iterator<User> users = datastore.find()
> .type(UserSkill.class)
> .addFilter("skill", EQUAL, "java")
> .addFilter("ability", GREATER_THAN, 5)
> .returnParentsNow();
>
> This is how easy it is to use Relation Index Entities with the new release
> of Twig
While I'm solidifying the opinion that the RIE pattern is actually
pretty useless, being able to fetch parent keys (or parents) does seem
to come up enough that we may add a shorthand for it:
Iterable<User> users = ofy.query(UserSkill.class).filter("skill",
"java").filter("ability >", 5).fetchParents();
Note that anyone can trivially fabricate their own implementation of
this boilerplate right now using Objectify's QueryWrapper class.
> Behind the scenes two queries are run *in parallel* asynchronously and then
> merged together into a single Iterator. Notice also that the two queries
> both inherit the common filter and sort on "ability".
This does seem quite interesting, and I congratulate you for working
out the underlying details :-)
The question I have is for our Google overlords: Why isn't the Java
SDK opensourced like the Python implementation? Yes, the DN plugin is
opensource, but that's the least interesting part!
Jeff
--
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 [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/google-appengine-java?hl=en.
