I appreciate your concern for Objectify staying clean, and consistent. It *is* good to have frameworks that offer different feature sets and ways in which they implement them.
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. I have been arguing for direct references since the beginning of Objectify. The problem has always been one of how to implement it. The difficulties have always been conceptual and performance related, not actually making it work ;) Some of the questions that come up are: how deep to you go down the object graph, what do you do about uninitialized objects (which might only have a key/id[+parent]), when do you get the children/referenced-objects, what transaction do you use (the same as the initial get, or can you specify one at each level), how do you deal with puts (do you cascade, or require the user to explicitly put what they've changed), do you support automatic "dirty detection" (related to the last question), are there any special behaviors with delete, does the implementation seem obvious (and clear) to the user? > 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. "Or" support should be trivial, as you have said. You just add an "Or" method to our query object (maybe changing the current "filter" method to "and"). All the work goes on below the covers. > 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. We have a lot of room to create some common shared utility libraries (for performance tuning/collection, async operations, mapping properties, etc.). In fact, it would be a great step forward if we could make sure the mapping for our objects follow the same naming scheme. For things like Embedded it is important that we represent the entity mapping the same so that people can changes from twig/objectify/other-framework without having to re-process all their entities. John, what do you think about that? > 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. It does strike me that much of our framework functionality is common, and therefor is probably a wasted effort (if we could work together with a shared code base). However, looking at the coding styles and philosophies I don't think we would (immediately) benefit from creating a common base framework without a lot of work. I do envy the twig ansync operations; although I worry a bit about using the Protocol Buffers interfaces. Sometimes it is good to have two teams working on the same thing. There is no question competition breeds better results (when it works). -- 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.
