[PEAK] A ridiculously simple mapping layer
Phillip J. Eby
pje at telecommunity.com
Tue Jul 27 11:53:50 EDT 2004
At 10:31 PM 7/26/04 -0700, Robert Brewer wrote:
>How interesting that you would choose the form 'ws.Customer' over
>'Customer.ws'; that is, why not just stick a reference to the workspace
>into each Customer instance when it's created? I assume you're buying
>something with your syntax, but I can't figure out what it is just yet.
>Do tell. ;)
It's that 'ws.Invoice()' creates a new invoice object that already knows
its workspace. The way you describe requires two steps.
It's also that any class or instance methods of the abstract Invoice class
can be overridden with backend-specific code if need be.
Finally, it avoids having two namespaces to deal with. Instead of pulling
the classes from your abstract model's module, and then repeatedly passing
them into the workspace, you just deal strictly with the workspace.
>For example (now that I've got the basic architecture), I need to build
>a traditional queue-on-read, lock-on-write cache. And nothing's stopping
>me from writing an admin tool which flushes a given cache and replaces
>it with another (with a different persistence style) on the fly. Tuning
>deployed apps when concurrency problems arise? Going to be a lot
>simpler, now. :) I think you'll find the same if you can isolate it as
I expect the actual mechanism to be based on generic functions, allowing
policies such as you describe to be implemented as before/after/around
methods. But I'm not 100% clear just yet as to where it'll all get hooked
up. The current _onLink() and _onUnlink() hooks of peak.model are where
the invocation will take place, but it's not yet clear to me whether the
generic functions will live in the features, the classes, the workspace, or
what. I'm also not clear on how many functions there will be. Finally,
I'm not clear on whether mutable peak.model objects will remain usable
outside of a workspace.
Right now I'm going over the requirements for both providing all the
current functionality of DM's, while expanding the basic capabilities. And
I'm also trying to balance things in my mind between making the class
conversion a general-purpose AOP facility, and making it extremely specific
to data mapping.
A lot of these tradeoffs would be simple to make in the abstract, but the
practical problem is how to get from point "A" where we are today, to point
"B" while not having any horrible breakage of functionality in
between. That is, I'd ideally like to modify things in a way such that
DM's still work until after the new machinery is available, thus allowing
people to migrate their existing DM-based applications before I remove the
More information about the PEAK