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 [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.
