sorry for this maybe thumb question, but I just want to make sure: both frameworks are making the needs for open session in view (as "almost required" when using jdo/jpa in web applications) obsolete, or?
regards, andr On 26 Jan., 12:18, John Patterson <[email protected]> wrote: > Hi Chau, yes both Objectify and Twig replace JDO/JPA. I think that > Google would not release a non-standard datastore user-level API > because they could then be accused by many of "vendor lock-in". When > App Engine was launched there was a lot of concern about this. > > On 26 Jan 2010, at 16:59, Chau Huynh 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 > > <[email protected]> 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 [email protected] > > . > > To unsubscribe from this group, send email to > > [email protected] > > . > > For more options, visit this group > > athttp://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 [email protected] > > . > > To unsubscribe from this group, send email to > > [email protected] > > . > > For more options, visit this group > > athttp://groups.google.com/group/google-appengine-java?hl=en > > .- Zitierten Text ausblenden - > > - Zitierten Text anzeigen - -- 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.
