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

[John Landahl]

Phillip J. Eby wrote:

> The hard part of the design, that I'm chewing on in my spare time, is 
> how to create a Pythonic FO notation, that won't end up looking like 
> Prolog or Lisp!

Funny you should mention Prolog; I was thinking of it while reading your 
description of FO concepts.  A Prolog-ish notation might not be such a 
bad thing.

> Indeed, the more I think about it the more I realize that trying to 
> implement a lot of typical business functions by direct mapping to the 
> OO paradigm actually *adds* complexity and effort.

I've been coming to this realization recently as well.  I only recently 
learned anything about Prolog, but it seems like there's a lot there 
that could be applied to these kinds of problems.  Have you looked at PyLog?

> This is both more and less granular than a DM.  When you have related 
> objects in two DMs, right now you must write code in both to save and 
> load the linking attribute(s).  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.

The "fun" part of this will be matching such relationships to underlying 
data structures in a way which results in efficient SQL.  One advantage 
of the DM approach here is that you can write highly tuned SQL when 
necessary because there's (often) a tight coupling between a DM and the 
underlying data structures.  (Ah, you mention this later on).

> Here, the idea is that a fact type such as 'order_total' is a protocol 
> that you can adapt the editing context to.  Thus, one would create 
> different EC subclasses to define a specific schema mapping.  The EC 
> itself doesn't actually implement anything, however.  Instead, you 
> simply declare adapters (probably sticky ones) for the fact types that 
> can be implemented in the schema.  And if a compound fact type doesn't 
> have a specific adaptation, it just creates a generic compound 
> implementation over the adaptation of the fact types it comprises.

Where and how would you define the underlying schema?