Hi Jeff and John: Wow! This is the spirit of open source where we can focus on what we are interesting in to Share our unique comparative advantages while learning and leveraging on others for the benefits of the Whole.
Thanks guys. Duong BaTien DBGROUPS and BudhNet On Sun, 2010-03-14 at 19:27 +0700, John Patterson 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.
