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