[TransWarp] TableDM proof of concept, request for comments
Phillip J. Eby
pje at telecommunity.com
Fri Oct 10 12:22:30 EDT 2003
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
* 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
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.
More information about the PEAK