[elephant-devel] Storing objects in the root when don't care about the key / add same key to root more than once

[Ian Eslick]

On May 28, 2007, at 9:26 AM, Joubert Nel wrote:

> On Mon, 2007-05-28 at 08:51, Ian Eslick wrote:
>> A few clarifications:
>>
>> Standard persistent classes are not saved by default.  To get access
>
> Ian, when are objects that are instanced from persistent classes  
> saved?
> I simply call (make-instance) on the following class definition:
>
> (defclass risk ()
>   ((title :accessor title :initarg :title :initform ""))
>   (:metaclass elephant:persistent-metaclass)
>   (:index t))
>
> the resulting object is immediately saved/persisted by Elephant...

I don't want to force users to take on the indexing overhead for all  
persistent classes.  The addition of the class :index option is what  
ensures that it will be saved.  This option is added by default if  
any slot is indexed.

>
>> to a class via the map-class operator the class or a slot of the
>> class must be declared as :indexed.  If a slot is indexed, then that
>> value can be used as a key for the object via the get-instances-by-
>> value interface.  Moreover, you can have duplicate slot values and
>> get-instances-by-value will return all the objects having that slot
>> value.
>
> Understood - this is what I got from the documentation as well.
>
>>
>> Think of the root more like a hash table (single key-value pair)
>> instead of a set or collection.  The simple get-value interface would
>> be more complex if it could return multiple values.
>
> My impression until I saw how persistent objects behave was that
> everything you want to store via Elephant had to be "rooted".

Did you read through the tutorial in the new manual?  I thought I put  
hints into the section on roots that you can store via indexed  
classes and then the details should have been covered in the indexing  
part of the tutorial.  Do you have suggestions on how we can clarify  
this point?

>>
>> It is poor coding practice to use system-assigned OIDs.  In future
>> versions of elephant OIDs may change over time due to GC, auto
>> recovery of oid space, etc.  It's sort of like using the physical
>> address of an object in a C++ program.  There is a legitimate way to
>> use OIDs outside of elephant, but we haven't yet defined an interface
>> for users to do so (for example you might want to use OIDs to create
>> many-to-many maps or efficient persistent sets)
>
> Thanks for this insight. Many-to-many maps and sets are exactly  
> what I'm
> trying to achieve.
> I found a newly released UUID package for Lisp -
> http://www.cl-user.net/asp/libs/uuid
> I'm going to explore using this instead of OIDs.

We would be interested in a solution that we could integrate as a  
contrib or as a standard component of elephant.  I wrote a many-to- 
many map awhile back that was just a btree where the key was the  
source OID and the targets were a vector of OIDs (assuming that the  
cross product was populated).  If you wanted to be able to to do the  
reverse you just create two of these btrees and ensure that they are  
always synchronized.  I'm sure there are more efficient solutions,  
but this is relatively simple.

There is already a persistent set class (PSET), but you don't want to  
be doing alot of operations on persistent sets because you can't  
reclaim the intermediate products.  There should be a tutorial  
section on PSETs that talks about this.

> Joubert
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel