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

[Ian Eslick]

> Right now all I want is “do what I mean” behaviour for SETF SLOT- 
> VALUE.
> AFAICS the current behaviour for this operation is that Elephant  
> attempts
> to stuff the object into the current sc instead of using the objects
> home controller. Which seems not exactly sensible to me.
>

Ok, I think I can clarify a couple of points (especially now that I've  
caught up on sleep! :)

What we're arguing about is the correct default behavior.  I think  
you're talking me around on supporting this functionality, however I  
want to make sure that you have to explicitly enable it.

The reason for this is that allowing objects to have more than one  
home store means that the semantics of other functions has to change,  
such as get-instances-by-class which now becomes get-instances-by- 
class-in-current-store-controller.  I'd like users to realize that  
this change is happening when it does.  If a user unintentionally  
creates an object in a second store, I don't want that error to be  
invisible.

Here is a proposal:

1) Writes to objects will always use that object's home store (as  
requested!)

2) The persistent-metaclass would be extended to support multiple  
class indexes; one for each store controller instances exist in.

3) We add an option to enable multi-store operation.  Unless multi- 
store operation is enabled, writing an object to a new store will  
result in a condition which asks if the user really intended to do  
this with a reference to the manual section they should read.

4) When multi-store mode is on, class+database synchronization is  
disabled.  This means that any indexes for a given class will be  
ignored if the class definition doesn't explicitly reference them  
(this just means that the index storage will be maintained, even if  
you choose to unindex a slot in the defpclass)

5) To fix the abstraction problems, we might want to add a facility  
when a store is opened to scan the data store's master list of class  
indexes and explicitly add the class index to the set of cached class  
indexes for that class.  This way the user can rely on the class  
knowing about all the stores that reference an object.  We could then  
implement 'the right thing' for get-instances-by-class, etc. by doing  
multiple map-indexes and merging the results.

6) Add a chapter to the manual expanding on the implications for  
storing indexed classes in multiple stores

I'll do # 1-4 now since it doesn't really effect anyone but you and  
maintains the current behavior for anyone else.  I can't sign up for  
#5-6.

This proposal should do the right thing for the common cases you want  
(esp. if we do #5), but make sure that people think about what they're  
doing before they do it and don't shoot themselves in the foot  
accidentally by creating objects that disappear.  The manual should  
talk about what parts of the class indexing abstraction will change.   
For example index-based queries of all objects or objects by value  
refer only to the objects in the current store, not to all instances  
of the class that may exist.  The user can continue and disable the  
warning for the current session.

I could explain why the current behavior is what it is, but I'd  
probably just confuse things further!

Regards,
Ian