[elephant-devel] Learning about Elephant

[Ian Eslick]

>
> Now, I think the last few questions I have on this subject before  
> delving further are
>
> 1) What data structure do associations use to store the list of  
> associated objects? My little understanding of update-association- 
> end implies that the association slot creates some sort of indexed- 
> btree.

It uses dup-btrees to maintain an index.  An association end is a  
mapping maintained by the associated (target) class of objects who's  
slot value points to an instance of that target class.  e.g.

(defpclass src ...)
(defpclass targ ... :associate (ref src))

(setf (ref inst-class-src) inst-class-target)

dup-btree based index on target might look something like this:
key: inst-class-target value: inst-class-src
key: inst-class-target value: inst-class-src2
key: inst-class-target2 value: inst-class-src3
...

:many-to-many simply maintains two indices for mutual pointers and  
allows both source and target to create more than one association  
between an instance of itself and the other class.  Experimentation is  
the best path to enlightenment.

> 2) Are they storing a reference to the objects themselves or just  
> the OIDs. It seems to me that it stores a reference on that "indexed- 
> btree". However, this (setf (get-value (oid target) index) (oid  
> instance)) in update-association-end seems to imply that it stores  
> the key/value using the OID.

I believe all indexing structures use OIDs directly.  See below.

> 3) Can the list be indexed in any way or do we basically need to  
> "manually" sort it to our liking once we retrieve the associations.  
> If my assumptions above are correct, the associations are indexed  
> based on OID sequence.

The user API interface (get-associated) returns instances not OIDs; so  
you can use lisp's sort to sort on slot values.  I think you can use  
an :oid argument to get back the oid list, but then that's all you can  
sort on.

> As a general question in reference to #2 above, does Elephant always  
> use the OIDs to store references of objects? I read on the list that  
> a while back someone (I think it was you) posted something along the  
> lines that we shouldn't use OIDs as unique identifiers because OIDs  
> could change. I suppose during migrations, when objects are re- 
> created, the OIDs change. Is that correct? Do the migrations take  
> care of updating all these OID references?

This is so we can pull the oid out of the serializer without calling  
controller-recreate-instance on the oid - this enables the query  
system to work entirely on oids and only recreate instances when it  
needs slot values or at the end of the query tree execution.  You are  
correct that migration renames all OIDs and that the migration process  
handles this renaming properly for all built-in indices.

> Now, a separate modeling question arises :) Imagine a many-to-many  
> relationship where the relationship needs to store additional  
> information. For example, imagine a membership club. Person1 becomes  
> a member of Club1 on 1/1/09 and is paid thru 3/31/09. We have a  
> class for person and a class for club, but when we store the  
> association between the two, we would like to store the "effective- 
> date" and the "termination-date" of the membership (association).  
> How would you approach that?

Create a membership class that encodes that relation with slots  
person, club, start, terminated.  You can't put everything into a  
single abstraction.  :)

Think of this class as somewhat analogous a join table in SQL.   
Indices on the slots will order these events or relations so you can  
read off start and termination dates in order, or clubs in order.  You  
can used derived indices to order based on arbitrary functions of the  
slots of an object.

> Thanks again,
> JD
>
> On Wed, Jan 28, 2009 at 12:32 AM, Ian Eslick <eslick at media.mit.edu>  
> wrote:
> That would be correct if you added (setf (friends-of person3) person2)
>
> On Jan 27, 2009, at 5:06 PM, John wrote:
>
> > Thanks for the clear example. However, maybe the idioms are
> > confusing me, but many-to-many tells me that I should be able to do
> > something like:
> >
> > (setf (friends-of person1) person2)
> > (setf (friends-of person1) person3)
> > (setf (friends-of person1) person4)
> > (setf (friends-of person1) person5)
> >
> > (setf (friends-of person2) person3)
> >
> > such that:
> >
> > (friends-of person1) => (person2 person3 person4 person5)
> > (friends-of person2) => (person1 person3)
> > (friends-of person3) => (person1 person2)
> > (friends-of person4) => person1
> > (friends-of person5) => person1
> >
> > Would that be the expected behavior?
>
> _______________________________________________
> elephant-devel site list
> elephant-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/elephant-devel