[Chandler-dev] Rearchitecture progress

Phillip J. Eby pje at telecommunity.com
Tue Feb 19 12:43:11 PST 2008


Just a quick note to remind anyone interested in the desktop 
rearchitecture branch, that I post/blog library-related design notes 
to the PEAK mailing list at:

   http://www.eby-sarna.com/mailman/listinfo/peak

For example, yesterday I wrote up some thoughts about 
object-relational mapping with the Trellis here:

   http://www.eby-sarna.com/pipermail/peak/2008-February/002862.html

I send these posts to the PEAK list as they are of general interest 
to other PEAK users, even though they often cite Chandler 
requirements as a driving force in design.  (Also, they are usually 
unstructured brain dumps of my thoughts, and so less suitable for 
posting here.  When there are significant new releases, however, I 
will usually post announcements here.)

Currently, I'm working on the storage layer for the rearchitecture 
branch, specifically investigating ways to map EIM (or "EIM 2") 
record schemas onto SQLAlchemy table schemas, and ways to use 
SQLAlchemy's mapping strategies for possible semi-automatic 
conversion between objects and EIM records.  I'm also working on 
designing what might be considered an EIM query/update API, to wrap 
SQLAlchemy and also serve as a basis for certain kinds of 
non-persisted application needs.  (For example, displaying generated 
recurrence objects that might not be actually stored in the 
underlying database.)

The expected programming model for storage will be to define an 
application class' EIM schema, and appropriate translation code 
(maybe in the form of an SQLAlchemy-like mapping 
specification).  Thus, all plugins will automatically have a 
shareable and dump/restorable schema, since they will need an EIM 
schema to work at all.  :)

And, as a side effect of having the mapping+EIM schema, it should 
then be possible to express queries as Python list comprehensions (or 
genexps) in the form of strings, so application level code won't need 
to deal in indexes and other such things.  Instead, SQL-level 
indexing and any other storage-specific optimizations will be 
specified via "hints" attached to the EIM schema.

As the specification and design progress over the next few weeks, 
I'll be posting the details to the PEAK list.  Again, keep in mind 
that such postings are highly stream-of-consciousness and shouldn't 
be considered official design documents, feature commitments, etc. at 
this time.  Any "stable" designs, announcements, etc. will still be sent here.



More information about the chandler-dev mailing list