I am in the middle of refactoring of the access stack prompted by the
requirements of the nested DataContexts. [Note to Marcin - not yet at
the point where we can start looking at client context optimization,
but getting there]. Here is the heads up...
The main challenge is to push any DataRow-related logic to the
DataDomain, so that the DB stuff is not visible above it. I more or
less succeeded in defining the channel interface that would allow to
nest contexts, but also (and this is pretty exciting) to
transparently intercept/analyze/alter all traffic from the
DataContext and down (makes DataContextDelegate.willPerformXYZ look
obsolete).
Now the high-level API changes:
* Former OPPChannel is moved to the top package and is now called
DataChannel. It is simplified, and more importantly it works as a
"container" for the child ObjectContext, registering fetched objects
with it. DataChannel is what makes possible stack interception and
customization I mentioned above.
* DataContext is now an ObjectContext and is no longer a QueryEngine
(rather its QueryEngine'ness is deprecated). There is still some
abstraction leak (namely DataDomain does a DataContext cast to make
sense of it), but from the user perspective DataContext is really an
ObjectContext with extra utility methods.
* QueryResponse interface is totally redefined. This is one thing
that may bite some early 1.2 adopters (I hope not too many, as
DataContext never used it before). In M10 and before it would store
query results keyed by Query. This is no longer possible, as queries
can potentially be substituted at some points down the stack, so
figuring what part of the result was produced by what query is
generally impossible. New query response simply stores an ordered
collection of all results of OPPChannel.onQuery(..) regardless of how
they were produced.
Andrus
P.S. Here is a comment from my last CVS commit:
1. Completely redefining QueryResponse interface to avoid mapping by
query
2. Changing the access stack to push the logic of converting query
results to objects (or transferring those objects to a higher level
Context) down to the lower level... This allows for nested channels
and keeping DataRow logic at the DataDomain level where it belongs
3. Intercepting SingleObjectQuery and RelationshipQuery - thus fault
resolution logic doesn't have to be hardcoded (and assume a certain
stack structure)... it works just like a query.
4. OPP idea (as a single protocol for local and remote context
chaining) didn't work out... So OPPChannel is now simply a
DataChannel... OPP package will probably be renamed to "remote" or
something.
This archive was generated by hypermail 2.0.0 : Mon Jan 30 2006 - 23:54:23 EST