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

[Phillip J. Eby]

At 12:30 PM 4/19/04 -0700, John Landahl wrote:

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

Some, yes.  Mainly in Prolog dialects that deal with databases.

>Have you looked at PyLog?

A long while ago.  IIRC, it doesn't do anything with databases.


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

That bit's trivial actually.  Well, straightforward at least.  :)


>>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?

Well, it's more of an "overlying" schema to me.  :)  I see it as being 
composed of "conceptual fact types", which define the conceptual properties 
of the fact type, such as its arity, role types, constraints, derivation 
rules, etc.

You then define adapters to implement the "physical fact types" that 
realize the conceptual fact types for a physical DB mapping.

But, to answer your question, you'll probably have modules that exist 
primarily to define the fact types, constraints, etc. for a given domain model.