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
_______________________________________________
elephant-devel site list
elephant-devel@common-lisp.net
http://common-lisp.net/mailman/listinfo/elephant-devel
