[elephant-devel] Cross-references and SETF SLOT-VALUE

[Ian Eslick]

On Feb 21, 2008, at 8:41 AM, Leslie P. Polzer wrote:

>
> I'm not sure I understood your message correctly. But see below.
>
>> Ok, this is an architectural issue that wasn't completely thought
>> out.  Currently class indexing effectively limits instances of a  
>> class
>> to a specific store.  The first time an instance is saved, the  
>> current
>> *store-controller* is used to create the class index tying the class
>> to that store.
>
> I do not have a problem with that.
> Actually, it's desired behaviour since the indexed objects of a  
> certain
> class need to belong to two different stores in my setup.

Do you need to do indexing operations across stores?  i.e. run a  
cursor over all objects regardless of which store they are in?

Ideally, what semantics would you like to see?


>
>
>>
>> I have a local patch which changes this behavior to create a class
>> index for each store's objects.  For example, in your test code, if
>> you call get-instances-by-class in the context of *sc1*, you'll get
>> nothing, in the context of *sc2* you'll get the instance you created
>> in *sc2*.  Each store has it's own local set of class indices.
>
> Isn't this the current behaviour?
>

Nope, the system only creates one class index independent of which  
store controller it's in, so you can only map indexed class instances  
to one store.

>
>> I'm concerned there are other areas where the policy choice becomes
>> difficult.  My inclination is to assert that if you want to index
>> persistent objects in multiple stores, you should plan for that
>> explicitly and not use the class indexing mechanism.
>
> I still don't understand why there's a problem with having SETF SLOT- 
> VALUE
> figure out the correct controller...
>

There isn't a problem doing this.  My concern is that this then  
creates the potential for other, less visible problems.

e.g. you create indexed instances in store 1, the class index  
associated with store one indexes all those instances.  When you call  
get-instances-by-class in the context of store 2, however, all the  
objects from store 1 are now missing.  The semantics of get-instance- 
by-class/value/range are all incorrect when you have instances stored  
in multiple store controllers.

Using multiple stores starts to break the model of a simple global  
namespace assumed by the current class indexing mechanism.  Rather  
than contort the class indexing mechanism to accommodate multiple  
store operations, my preference is that users write their own indexing  
mechanism that has the semantics they care about.



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