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