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

[Leslie P. Polzer]

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

No, I don't do this at the moment. I might later, so let's postpone
that point.


> Ideally, what semantics would you like to see?

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.


> 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 really having difficuly correlating what you say here to my
experience. I can happily have separate sets of indexed objects
with separate store controllers, or am at least deluded in a
convincing way :)

So I suppose it's my own dumbness again that's preventing me
from understanding correctly what you say here.

What you say here is that there's only one index for all controllers,
but otherwhere you state that the problem is separation of
controller indexes... I'm confused.


> 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.

It makes good sense for me, since I'm used to the model of store
controllers as objects with a very high grade of separation.
So when I change the sc, everything is different.
And this fits my current project well, too.


> 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.

It depends on what you intend here.

If the aim is global indexing across controllers, let's have it your
way with user-based indexing. It makes sense.

But if we talk about the thing as I see it, i.e. indexing separate
for all controllers, let's just fix the system so it behaves well
in this context.

  Leslie


-- 
My personal blog: http://blog.viridian-project.de/