Yes, while the "debate" has been a lot of fun (probably mostly for John and I), we probably agree on far more than we disagree. There are some mild philosophical differences and some aesthetic differences but truth be told, the problem space is pretty small. And I think John has done a lot of excellent work.
We're probably going to chew on the uninitialized entity/activation issue for a while. Despite the risks, I rather like the concept (without automatic activation), Scott seems have other thoughts. For parallel queries, we haven't really started talking about the API, but I have to admit there is a lot of appeal to simply adding a method like this on the Objectify interface: Map<Query<?>, Iterable<?>> multiquery(Iterable<Query<?>>); While not as powerful as being able to get(), put(), delete(), and query() at the same time, it probably covers 85% of the use cases with a very simple API. And yes, we'd certainly be happy to work on common code. I'm not familiar with the new Twig codebase (I only looked at it long ago, before starting Objectify) but it's on my (eventual) TODO list. So little time, so much software to write! Jeff On Sun, Mar 14, 2010 at 4:27 AM, John Patterson <jdpatter...@gmail.com> wrote: > > On 13 Mar 2010, at 11:00, Jeff Schnitzer wrote: >> >> since you can (and IMNSHO probably should) always disable automatic >> activation and refresh the graph manually. > > Although I dislike premature optimisations such as this note that you can > configure Activation to not activate any Objects by default. > >> After you explained the concept of uninitialized entities (the brief >> blurb in your docs really isn't enough), I actually rather like your >> solution! I might even implement something similar in Objectify. But >> I really think you need to document the hell out of the issues >> surrounding them. It is very very easy to corrupt data. > > Despite all the talk about differences in "philosophy" and the "down > playing" of the features in Twig I can see from the Objectify mailing list > that discussion has already started on how it would be possible to add > support for direct references and async parallel commands. > > Be very careful not to end up with an API that bulges with features that are > tacked on as an after thought. The Objectify Query API as it is now would > need to explode with permutations. Perhaps it is best to stick to the goal > of being a more usable object capable interface to the low-level API? > Objectify does this very well. > > When Twig started as not much more than a thin wrapper around the low-level > interface and grew in complexity as more high level Object oriented features > were added it became obvious that mixing direct references and low-level > Keys and Queries in the same API is just not manageable. So I stripped out > almost all the low-level references and the result is a very clean, focused > API. > > Adding a collection of helper functions to Objectify for things like merging > OR queries would very soon become unorganised and make exploring the API > difficult. > > You should probably make a decision about the design goals of Objectify and > stay true to it. There is always the option of building a higher-level > interface on top of Objectify - now that would be interesting! In Twig you > have the option to drop down to use the low-level datastore service if you > really need to - but the necessity for this has decreased a lot with the > final release 1.0 > > Although this our-answer-to-the-great-question-is-the-only-logical-one > banter is terrific fun it might make sense to work on some functionality in > common. Scott and I briefly mentioned making a common profiling ApiProxy to > help understand the performance of your app. I've made a quick start on > this but it really is a feature that makes sense not just for Twig. > > If the feature sets of Twig and Objectify end up converging over time - > albeit with differences in default settings - it begs the question if there > might be some way to cooperate on higher level functionality also. > >> OR queries haven't been a pain point. Maybe they will >> be in the future, in which case we'll consider adding the feature. We >> are content to wait for the request. > > > -- > 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. > > -- 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.
