[elephant-devel] Add indexed persistent class slots to elephant?

[Ian Eslick]

Robert L. Read wrote:

> On Tue, 2006-01-24 at 10:46 -0500, Ian Eslick wrote:
>
>> Ok, I'll stick myself on CVS so I can push things over incrementally and
>> back things out more easily in case of damage (plus keep up to date on
>> change you and others are making).  Did I hear that someone was working
>> on GC for persistent objects?
>
>
> I don't think any serious work has begun on GC for persistent objects; 
> I think the idea has lauded.
> I think it would be nice.

But probably not critical just now.  GC is a fair bit of work and the 
benefit is only realized when it starts to become a real problem for 
people.  What I'm doing will interact with GC as reclaimed objects need 
to have the associated key/value pairs dropped from slot-indices.  
Slot-indices should be like weak hashes...but if they're stored in the 
main btree table that may not be so easy depending on how GC is 
implemented.  It might make sense to add a weak option to btrees when it 
comes time to get around to GC...maybe lazily drop reclaimed instances 
when referenced.

That reminds me.  Without GC and/or renaming oids we'll eventually run 
out of OID address space, again when the DB gets enough use.  I haven't 
seen any provisions for fixnum wrap-around.  Am I missing something or 
is this correct?

Anyway, if I use existing btrees as a common base on which to create the 
two ways to use slot indexes, I'll need a canonical way to associate a 
persistent class with its btree indices.  I can store a separate root 
index in the controller and have the accessors indirect through that to 
find the appropriate slot-index but how do I bootstrap this new 
persistent root?  The root is bootstrapped through :from-oid -1.  I 
could have another default btree at oid = -2 for the special persistent 
slot indices.  Alternatively I could pollute the root by storing the 
slot-index in a very long symbol stored as a key in the root index. 

Thoughts?

Ian