There aren't current plans to create yet another API for datastore operations. That's why we created the datastore API - so folks could build convenience functions as needed.
I don't see anything wrong with mixing JDO/JPA with another tool for datastore access, other than adding unnecessary complexity to your application. You can already mix JDO and JPA, though you'll get confused real quick. You'll want to be careful, though, since some third-party libraries may reuse annotations. It's easy to get confused. As far as the vendor lock-in point goes: that's about the last thing we want developers to worry about. There's an open source project that aims to recreate App Engine's datastore that can be run outside our cloud. I can't quite remember the name of it, but I'll post the project when it comes to mind. On Tue, Jan 26, 2010 at 1:59 AM, Chau Huynh <cmhu...@gmail.com> wrote: > Thanks John and Jeff for sharing the knowledge. > I've just quickly scanned your project home, and I have a novice question > that needs your help: > Is twig or Objectify direct replacement to JDO / JPA on GAE? I just need to > use your framework alone, or should use in combination with JDO / JPA > support? > > What is about the approach implementing "general" JDO / JPA fit to > Datastore? Is there a chance Google provide a specific implementation to > their Datastore? > Maybe someone from Google can advise on this? > > Thanks, > -Chau > > > On Tue, Jan 26, 2010 at 2:52 PM, John Patterson <jdpatter...@gmail.com>wrote: > >> >> On 26 Jan 2010, at 13:37, Jeff Schnitzer wrote: >> >> >> I can't resist a conversation about framework design philosophy :-) >> >> >> Oh go on then. Just a quickie. >> >> >> 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. >> >> >> Twig and Objectify operate at very different levels of abstraction. With >> Objectify you code at a lower level very aware of what is happening at the >> datastore level. It involves more work but, as you point out, if something >> goes wrong - it goes wrong in your own code where you are in a better >> position to handle it. >> >> With Twig you operate at a higher level that makes the persistence layer >> almost completely transparent. One major advantage of this is that you can >> change the way the data is stored (i.e. embedded or separate entity) without >> changing your code. Making such a change with Objectify means you need to >> rewrite your reference handling code yourself. >> >> >> 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. >> >> >> This is why you configure what type of relationship is used using: @Embed, >> @Entity(PARENT), @Entity(CHILD) or @Entity(INDEPENDENT) >> >> So you have the flexibility to choose configuration _without_ rewriting >> your code. Very important difference. >> >> Currently the first type of representation is not an option. I do want to >> add this as it makes very large collections that change often much more >> efficient. When it is added you could reconfigure your data schema by >> changing a single annotation. Such a change in Objectify would require the >> developer to rewrite their entire data layer >> >> 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? >> >> >> Yes instances are just normal POJOs so no problems serializing. I do this >> myself with GWT. >> >> Currently, lazy references are not supported... its a very important >> feature on the TODO list. >> >> >> 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 >> >> >> An inconsistent datastore is a problem with any framework - including >> Objectify. The trick is to use transactions where possible whenever working >> on an entity group to avoid getting this situation in the first place. >> >> * The Album could have a List<Key> property, and some of the Keys >> could point to Photos that do not exist >> >> >> As above. An exception would be thrown saying which property on what >> object could not be found. >> >> 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. >> >> >> If your data is inconsistent you have a problem - whether the framework >> throws an exception (as in Twig) or if you receive a null back from a finder >> method (as in Objectify) there is really not much difference. You still >> have to clean up the mess. >> >> 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. >> >> >> I think that for simple cases and small data models working with Keys and >> handling the references yourself is fine. When things get more complicated >> it is easier to reconfigure how the data is actually stored if you can >> simply change a configuration option in one place. >> >> 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. >> >> >> Obviously we agree to disagree on this point :) I much prefer letting he >> framework handle repetitive boiler plate code with minimal configuration. >> >> 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 :-) >> >> >> Nice one. It has honestly increased the performance of some queries by a >> factor of 10 at least. >> >> Jeff >> >> >> John >> >> -- >> 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<google-appengine-java%2bunsubscr...@googlegroups.com> >> . >> For more options, visit this group at >> http://groups.google.com/group/google-appengine-java?hl=en. >> > > -- > 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<google-appengine-java%2bunsubscr...@googlegroups.com> > . > For more options, visit this group at > http://groups.google.com/group/google-appengine-java?hl=en. > -- Ikai Lan Developer Programs Engineer, Google App Engine http://googleappengine.blogspot.com | http://twitter.com/app_engine -- 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.
