Re: SETFable join slots?

Sorry it took so long to reply to this.

What kinds of problems have people been having with the object- 
relational mapping?  I'm planning on writing production code with  
these mappings and while I haven't noticed any problems yet, it would  
be good to know what to expect.  :-)

One behavior that seems a little dangerous is this: if the user  
doesn't specify that one field is a primary key in the DEF-VIEW- 
CLASS, then calling (update-records-from-instance foo) will set the  
columns in *all* rows of that table to the appropriate value in foo.

Bill

On Aug 22, 2006, at 12:49 PM, Kevin Rosenberg wrote:

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