[PEAK] A ridiculously simple mapping layer

[Phillip J. Eby]

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
>you describe.

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 
old stuff.