On Feb 23, 2008, at 4:03 AM, Leslie P. Polzer wrote:
2) The persistent-metaclass would be extended to support multiple
class indexes; one for each store controller instances exist in.
I suppose that's the architectural issue you were talking about,
but which I didn't fully grasp because I h
> 2) The persistent-metaclass would be extended to support multiple
> class indexes; one for each store controller instances exist in.
I suppose that's the architectural issue you were talking about,
but which I didn't fully grasp because I haven't looked at the code.
> I'll do # 1-4 now since
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 c
The problem lies in an implementation choice. It can be changed, but
it's not as easy as it sounds.
1) The class object caches the class index reference. It currently
can only maintain a single cached reference. (from metaclasses.lisp)
(defclass persistent-metaclass (standard-class)
((
> 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
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 tim
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-controlle
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 just looked at the code and it appears to call 'get-con' in all the
right places. The code certainly is structured to do what you suggest
(get controller from the instance slot). I'll chase this down
tonight. Perhaps some recent change created a corner case that the
tests don't catch,
