On Mon, Jan 25, 2010 at 12:02 PM, John Patterson <[email protected]> wrote: > ... and then Twig makes it even easier! Because it supports direct > relationships (without Keys) and can translate any type into a Blob for you > your data model doesn't need to deal with low-level types at all > > So you example becomes: > > class Album { > �...@key Long id; > String name; > List<Photo> photos; > } > > Notice how your data model is not polluted by domain classes
I can't resist a conversation about framework design philosophy :-) This sort of binding (property of List<Photo>) can be convenient in some applications, and as a longtime Hibernate user I got used to working like this. But I don't like this abstraction in AppEngine. Yes, for some apps you might be able to remove the "pollution" of framework classes like Key (or OKey), but it comes with a price. A one-to-many relationship between Album and Photo has several "standard" representations in AppEngine: * The Photo could have a Key property pointing to Album * The Photo could have a parent ancestor in its Key which points to the Album * The Album entity could have a List<Key> property pointing to its Photos Each choice has a dramatic impact on performance, what can be done in a transaction, and how you do queries that simply cannot be glossed over or abstracted away. Which does the List<Photo> represent? Furthermore, is List<Photo> a proxy or did the photos get fetched along with the Album? Can I serialize the Album or do I need to detach it? Even worse, there are also two more possible representations: * The Photo could have a Key property (or ancestor) pointing to an Album that does not exist * The Album could have a List<Key> property, and some of the Keys could point to Photos that do not exist Maybe these are degenerate cases, maybe not, but you'll never be able to completely avoid them. RDBMSes have transactions and referential integrity constraints that guarantee these later two cases can't happen. Not so in AppEngine. You're just one DatastoreTimeoutException away from having to deal with this situation in your code. This is the big mess that makes JDO on Appengine so complicated, possibly even more complicated than it is on an RDBMS. On the other hand... if you simply expose the Key (or OKey), the developer does a little more work but doesn't have to figure out all the configuration. Without proxies, all entities are serializable and GWT-able without any special consideration. Actualy, JDO doesn't even offer all the necessary configuration options, which is probably why you end up seeing Key a lot as properties in JDO sample code. So.... while it seems like you might be able to keep Key and other framework classes out of your entities... for many applications I don't think it's realistic, and for most, I don't think it's a good idea. IMHO, of course. > Another feature only supported by Twig is embedded collections - this allows > you to do a single query for Albums containing a particular photo for > example. In JDO, Objectify or any of the others this requires multiple > queries. You configure it with a single Embed annotation like this: We like this feature and are assimilating it now :-) 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.
