Late night thoughts
TKCS is a first-generation "do anything" database for intrinsicly persistent objects. AgileWiki is a "do everything" application which sits on this database. TKCS offers simple text properties, simple link properties, text set properties, link set properties, documents, lists of links and dictionaries. It offers internal links, normal links and external links, and an innovative persistent memory management system built on these link types. Plus it is change-based. And it takes about a megabyte of metadata to configure it for AgileWiki. But then, its a first generation that doesn't extend too much beyond graph theory.
I've been thinking of a second-generation approach that would be more powerful, retain the persistent memory management system, but require only a minimum of metadata. It would be based on 2-column tables, a key and a value.
A table is interesting. You can use the key to access the value, like a dictionary. But you can also order it, like a list. I would suggest having normal, internal and external tables, with internal tables having an associated text document (a blob).
Table names would be prefixed with a high-order token, >chr(127), to distinguish a text value from a link to a table. (Every table can contain a mix of links and text values) Further, that token prefix would itentify the type of table (normal, internal or external). And hey, that's the end of the metadata. :-)
Structures are comprised of a single internal table and the other (non-internal) tables referenced by it. And external tables can only reference internal tables. This keeps structures pretty simple, which is important 'cause they are user-level objects! (Well, not every structure needs to be accessible by every user--some would be configuration/descriptor data to drive the application logic.)
Every table must be referenced by either an internal or external table, except for the root table. Further, if you look at the links of all internal and external tables taken together, it forms a non-cyclic graph.
Let me know if you're interested in working on this. It sure would be nice to work with a group again. And it would be a good excuse to learn subversion. :-)
Oh yes, note that none of this would depend on compstrm or co-routines. But like TKS, it would be change-based.
Bill
posted by Bill la Forge @ 9:29 PM
1 comments
1 Comments:
Hi Bill,
As you know, I'm concerned about the present persistence layer not being based on the Python DB API, which restricts the selection of backend storage. Further, the whole topic of implementing object <-> relational mapping in Python has been addressed in several current modules, e.g. , Durus, ForgetSQL, MiddleKit, PyDO, PyTables, Roundup's HyperDB, and SQLAlchemy. Several others are more or less Zope/ZODB oriented projects, including APE, Dejavu, Hornet, SQLObject, and SQLStorage. AFAIK, all of those are backend agnostic.
Some only work (today . . .) with a few backends, such as Qlime. That can be justified, as in the case of Cucmber2, which leverages the native Object Relational features of my faovrite ORDBMS, PostgreSQL. However, it cuts against the stated concern of providing user choice at the storage layer. Still, as long as it is based on the Python DB API, the few extensions could be compensated for, when another backend is prefered.
Anyhow, to the point. It may be worth a little time to investigate how these work, in order to make the most of the Open Source Community process.
Links:
http://issola.caltech.edu/~t/cucumber2/doc/
http://blogs.nuxeo.com/sections/blogs/florent_guillaume/2005_08_11_object_relational
http://projects.amor.org/dejavu
(sorry, this one is Google cached, so it is way long)
http://64.233.187.104/search?q=cache:IUXEd5AlYdsJ:www.amorhq.net/blogs/index.php/fumanchu/2005/08/11/where_dejavu_fits_in_the_orm_cosmos+%22Where+Dejavu+fits+in+the+ORM+cosmos%22&hl=en&lr=lang_en&client=firefox-a
http://www.qlime.org/
http://soiland.no/software/forgetsql
http://webware.sourceforge.net/Webware-0.8/MiddleKit/Docs/Intro.html
http://skunkweb.sourceforge.net/PyDO/
http://www.blogger.com/comment.g?blogID=9431139&postID=113786227386804339
So, I'd be interested in participating in the process of revising the present storage mapping layer, in the stated direction. Since there is a Python module for BSDDB, the option to keep that storage platform should remain available. I can't tell from the documentation whether it is Python DB API based, however:
http://pybsddb.sourceforge.net/
Thanks as always for sharing your facinating work!
Jerry Spicklemire
Post a Comment
<< Home