Re: SETFable join slots?

Bill Atkins wrote:
> One thing I'd like to do with CLSQL is:
>  (push *bob* (account-customers *yoyodne-inc*))
> where ACCOUNT-CUSTOMERS is a join slot.  Then when
> [...]
> that CLSQL supports this now - are there subtle, hard-to-get-right
> issues with this, or is it just that no one has added this support
> yet?  If the latter is the case, I plan to add support for this within
> [...]

Hi Bill, I have a few preliminary thoughts about this:

1. This brings up the whole issue of join slots and object
relations. My goal for CLSQL was to meet the specifications of the
Common Lisp documentation. One recurrent issue of the mail list has
been that the object relations don't do as much as some people think
they should. That's a fair observation. I haven't made any attempts to
add functionality beyond the CommonSQL specification. Personally, it's
rare that I use the object-oriented interface at all. I tend to use
optimized direct SQL statements using the "functional" model.

More disturbing, though, is how a some have said on the mail list that
the object relations don't work as they expect them to. Indeed, some
patches have been proposed to change the join behavior. You can see
them in the mail list archives.

Before adding more functionality (which has the chance of being
misunderstood or misused), I'd like to see more tests added to the
test database to ensure that the current join behavior is currently
meeting people's expectation. Then, any additional functionality would
need to come well-documented in the docbook files as well as with
tests in the test suites.

While this may seem overly conservative or an impediment to rapidly
deploying functionality you might need, it's been my experience that
the object joining has been one of rougher areas in CLSQL and I don't
want to add to any ambiguity or surprising behavior that may already
exist.


2. Adding a new means for an object to get modified in memory adds to
the potential issue of ensuring synchronization between objects in
memory and in the database. While CLSQL maintains an object cache (to
meet the CommonSQL specification), this cache is merely for
performance sake. 

I think adding the concept of 'singletons' would be
worthwhile. Singletons would ensure that every object made with a
unique primary key would be EQ to objects with the same primary
key. 

Having a cache already helps since CLSQL would need to cache each
singleton so requests for an object with the same primary key would
return an identical object. Reworking the caching to maintain
singletons isn't necessary for your extension. But, the more ways that
an object can be modified in memory increases the possibility that
some user will have two objects in memory that they think represents
the same object, but an operation on one object leaves the other
in-memory object in a different state.

So that's my initial feedback on your "subtle issues, hard to get
right" question. While broad in scope, it should give you an idea of
the direction that I think extensions to object relation model should
go.

-- 
Kevin Rosenberg
[email protected]