[Dev] Python Object Persistence

Paul Snively psnively at earthlink.net
Sat Nov 9 20:26:38 PST 2002


If we're investigating options for persisting Python objects and expect 
to layer RDF model semantics atop those Python objects, may I humbly 
suggest that some interested party please take a look at 
<http://www.equi4.com/metakit> and its Mk4py interface, which 
apparently includes a MkMemoIO.py class that implements IO in terms of 
MetaKit Memo fields, thereby making them suitable for use with Python's 
pickling module?

Alternatively, it might be interesting to attempt to write a ZODB 
interface to MetaKit as an alternative to Berkeley DB.

Of course, all of this is based on the assumption that the low-level 
code should only worry about persisting Python objects and that the 
interesting semantics will be implemented at a higher level. I find 
this assumption questionable, and still feel that Chandler would 
benefit from a graph-oriented model at the C++ level, which would then 
be exposed to Python. I guess I'm hoping that we can revisit the 
e4Graph question, although I understand concerns about scalability 
(e4Graph uses MetaKit, and MetaKit wants to be able to mmap() its 
entire file, so the scaling issue is about maximum total address space, 
unless you use MetaKit in a more, er, "meta" fashion to provide 
metadata and transactional integrity for data that isn't actually 
stored using MetaKit, an idea that I heard straight from MetaKit's 
developer, Jean-Claude Wippler).

Personally, though, I'm not sure I buy the idea that a PIM--even a 
shared one--needs to individually manage >2G worth of data, and in any 
event, it seems like an issue that could be revisited once we had some 
practical experience under our belts.

So. Is anyone in the persistence biz at OSAF willing to at least take 
Mk4py and MkMemoIO.py for a spin and report on the results?

Best regards,

More information about the Dev mailing list