[PEAK] DM refactoring and asynchrony (was Re: PEAK and Twisted, revisited)

[Robert Brewer]

Phillip J. Eby wrote:
> >f = logic.Expression(lambda x: x.Amount > 127)
> >trans = namespace.recall(Transaction, f)
> >The current downside is that I'm using CPython-specific
> >bytecode hacks both in the formation of the Expression object
> 
> I'm not clear why you'd need bytecode hacks at all.  It seems 
> to me that 
> one could simply call the lambda expression with an object 
> designed for the 
> purpose, to extract its logic.  Indeed, if you don't mind 
> using &&, ||, and 
> ~  (for "and", "or", and "not" respectively), you don't even need the 
> lambda part.

Heh. I had an earlier version which did exactly that. The issues came
down to:

1) I really *did* mind using & and |, and
2) Since it operated on the "object designed for the purpose", the
syntax ended up looking like:
   a) A computed value, which then was never bound to a name (just
thrown away), or
   b) An assignment which didn't actually assign its referent.
   Both of them were too "unPythonic" for me to swallow... :)

Oh, and Dejavu caches the returned objects, so 3) you can pass those
fully-formed objects to the lambda and get evaluation without further
"logic extraction". That was probably the biggest "cool factor" at the
time I made the switch.

> I think my post may not have been clear here about what I was 
> seeking.  I 
> was looking for a Pythonic way to express schemas, more than a way to 
> express queries, although I'd like the syntax to be 
> consistent across both 
> queries and schema definition, since schemas involve rules that are 
> quantifiers over queries.  (E.g. this condition applies for 
> all X, or no X meets this criterion.)

Ah. Sorry, I joined the list after your initial post and was replying to
someone else's reply.

> > > The same thing in an FO
> > > approach would
> > > > correspond to a single fact type, pairing the two objects.
> > > So, there
> > > > would be only *one* implementation of that fact type, 
> handling both
> > > > sides of the relationship.
> >
> >As I describe above, I leave it to the DM to decide whether or not it
> >can optimize such relationships. The Python code is the master model.
> >FWIW, I have a namespace.associate() method, which adds 
> methods to both
> >the near and far classes to look up each other. For example, 
> to retrieve
> >all Ledger objects for a given Transaction, you write:
> >
> >for ledger in aTransaction.Ledger():
> >     ledger.do_something()
> 
> Heh, if you think that's a slick way of doing it, you should 
> have a look at 
> the "Active Record" framework that's part of Ruby's "Rails" web 
> framework.  It's the most terse way of describing an object 
> schema I've 
> ever seen.  Hell, it *figures out whether an attribute name 
> is plural*, and 
> then takes the singular form to look up a type name!  That's 
> actually far 
> too much guesswork for my taste, but you sure can't beat the 
> brevity with 
> which one can describe the schema.  :)

I actually considered that (singular/plural approach) at one point. :)
But I figured that would inhibit users of the framework too much.

> >Of course, Dejavu isn't anywhere near the complexity of PEAK, or even
> >address the exact same domains (I make plenty of assumptions about my
> >data that PEAK can't), but it's interesting to discuss 
> similar problems
> >across models. I look forward to learning more about about 
> PEAK as time
> >permits.
> 
> Yeah, PEAK is a bit hard to sum up in brief.  PEAK's entire 
> persistence 
> machinery and domain modelling aren't even part of its core; 
> they're just 
> one of its handy non-core frameworks.  And as you may have 
> seen from my 
> most recent post on this topic (re: removing ZODB4), you'll 
> see that those 
> parts are going to be changing quite a bit.
> 
> At least peak.binding is relatively stable these days.  (He 
> says, crossing 
> his fingers for luck...)

Well, then, good luck!


Robert Brewer
MIS
Amor Ministries
fumanchu at amor.org