Mike Orr wrote:
> On 10/13/06, Patrick K. O'Brien  wrote:
>>
>> If you'll recall a discussion from a while back, I made use of slots
>> throughout the Schevo fork of Durus, which saved a lot of memory at the
>> expense of arbitrary attributes.
>
> Excellent idea! I put .__slots__ in the main chemical object and the
> memory use cameo down to 121 MB (from 150).  Since this class is
> non-persistent and I only have five or six persistent classes in the
> database (all BTree or PersistentDict's), I don't think it'll help
> much to use a modified Durus but I'll give it a try. Maybe it will
> help all those BNode objects?  I'm installing Schevo now.  It's
> drop-in compatible with Durus?

The Schevo fork of Durus should be completely compatible other than the
slots difference (which forced a change to the ghosting process as well).

>>  I seem to recall that you didn't want
>> to give up your arbitrary attributes, particularly on the root object.
>
> I withdraw that objection. I switched back to using keys on the root
> object.  I was trying to make the database more transparent to the
> rest of the application, but now I have a domain class that handles
> all database access.
>
> There's no technical reason the root object has to be a
> PersistentDict, is there? It could be any Persistent object? What
> about an argument to the Storage constructor thus:
>    root_factory=PersistentDict
> Then ppl can make databases whose root object is their own custom
> container.

That would be cool, although there would be backward compatibility
issues.  IIRC, right now Durus assumes a certain type of root and
expects to be able to unpickle it as such.  The unpickling process would
not be as straightforward if the root could be something else.  I think
the flexibility could be achieved, but there are ramifications.

--
Patrick K. O'Brien
Orbtech       http://www.orbtech.com
Schevo        http://www.schevo.org
Louie         http://www.pylouie.org