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

[Phillip J. Eby]

At 02:04 PM 6/1/04 -0700, Robert Brewer wrote:

>I'm quite pleased with the technique I settled on for Dejavu (which is
>OO, not FO): I realized that lambdas are the perfect "limiting language"
>for filtering on object attributes. There are certain actions you cannot
>naturally perform within a lambda (such as assignment), and this nicely
>constrains them for use as a query construct. For example, to recall all
>'Transaction' objects with an Amount attribute greater than 127, you'd
>write:
>
>f = logic.Expression(lambda x: x.Amount > 127)
>trans = namespace.recall(Transaction, f)
>
>If a Dejavu StorageManager (like a DM) needs to evaluate that, it might
>convert the logic.Expression to an SQL string and return matching
>objects. The current downside is that I'm using CPython-specific
>bytecode hacks both in the formation of the Expression object (mostly
>early binding of globals, and distilling constants down), and in the
>derivation of the SQL. However, for my purposes, the "Pythonic syntax"
>far outweighs the portability concern. By the way, the 'logic' module
>(and codewalk.py, upon which it depends) is one folder up on my website
>from the above.

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.



> > If instead one creates form tools that are based on an FO perspective,
>
> > however, this issue vanishes.  One isn't doing 'x.y' in the first
>place,
> > but rather searching for 'x has y of ?', and expecting a collection of
>
> > matching facts.
>
>This could be implemented within my lambda syntax quite easily. All Unit
>classes (Unit is the superclass for all Dejavu persistent objects)
>currently get a 'has' method to facilitate associations between
>Units--the equivalent SQL might be "WHERE EXISTS(SELECT * FROM farClass
>WHERE farClass.parent = ID)". In Dejavu, if a DM manages both the near
>and far classes, it's free to use that SQL. What I'm getting at is if
>you control the core objects, it's no great leap to implement "x has y
>of ?" as "x.has(y, 3)" or something similar.

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.)


> > 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.  :)


>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...)