Hey Scott, some good ideas there.
On 14 Mar 2010, at 23:00, Scott Hernandez wrote:
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?
All valid concerns. I have implemented the most simple strategy that
works because - well it was fast and gets the job done. Stores are
all explicit for every instance which was also the most simple
implementaion. Basically the graph of references is walked and
instances that are already known about (because they were loaded and
cached) are passed over.
The next step will be manual dirty detection using a callback to the
ObjectDatastore - basically just a set of dirty instances that are
updated at the end of the unit of work. This way no extra state needs
to be stored per instance.
Then comes the class enhancement - AspectJ or a bytecode library -
then comes serialization issues ;)
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.
Sounds good. Will help me integrate that in-place upgrade stuff too.
I might need that on my next project that is more dynamic.
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?
All good. Another area is the persistent representation - i.e.
property naming so data could be shared. Perhaps a simple adapter
might suffice. That would be very interesting - it would mean a Twig
user could run Objectify in-place upgrades. Or an Objectify user
could run Twigs revertible isolated upgrades.
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 did think about the possibility of building Twig on top of Objectify
instead of the low-level interface. But it would probably add a
little more overhead and not be visible in the API anyway. There may
be better ways to share functionality.
I do envy the
twig ansync operations; although I worry a bit about using the
Protocol Buffers interfaces.
Im sure they will be opened up soon enough and officially supported.
I remember a comment from a Ikai about having no standard way to do
async queries in JDO. Maybe now it will receive a bit more attention.
Sometimes it is good to have two teams working on the same thing.
There is no question competition breeds better results (when it
works).
Yeah and it is good to have clear differences in approach so users can
make a decision based on their own preferences.
Cheers,
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 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.
