[TransWarp] TableDM proof of concept, request for comments

[Phillip J. Eby]

At 03:09 PM 10/10/03 +0200, Ulrich Eck wrote:
>what would be the preferred way of collaborating on this ?

Beats me.  My headache right now is that the scope of the open design 
decisions are too broad for me to think clearly about.  So, I need to find 
a way to reduce the solution space a bit.  I'm thinking the best thing for 
me to do is work on refactoring the existing peak.model.queries system to 
look like the "selector" system, but without any support for SQL, etc. as 
yet.  That would make them only useful with e.g. UML models, but that's 
better than nothing.

Some of my requirements for the query system:

* It should be possible to express the logical equivalent of virtually any 
OQL that doesn't involve aggregates or structures

* It should be possible to use a selector as a fast filter against 
in-memory Python objects

* It should be possible to use a selector as a precondition for a business 
rule or other dispatch operation (e.g. selectors should be adaptable to 
peak.util.dispatch.IRule)

* Ideally, there should be a way to express more than just filtering via 
selectors.  See http://www.orm.net/queries.html for ideas.

With a well-written foundation for expressing queries, it would narrow the 
design scope to just the issues of schemas, tables, and adapters 
thereto.  Actually, the next step after a model for expressing object-level 
queries, would be a model for expressing relational ones, independent of 
SQL syntax, but translatable to SQL, the way Castor's database "drivers" 
do.  That may or may not end up influencing the design of the table/schema 
metamodel.

Another place to look is the CWM spec; CWM already includes metamodels for 
tables, indexes, keys, queries, expressions, and a whole lot more.  We may 
not use that metamodel directly, but it's certainly worth looking at.