Re: Bug in 'update-records-from-instance'

Saurabh Nanda wrote:
> I think the standard can be extended by saying that, if a database
> connection is explicity passed that DB connection is used. Else, it
> uses the DB connection associated with the object iff it is open. Else
> it attemps to use *default-database*.

Well, yes, an extension could me made. In general, I'm not a big fan
of mapping objects to databases given the differences in semantics
between in-memory objects and database records. However, to have the
most success with ORM, I think having a consistent conceptual model is
important to avoid having surprises when trying to map objects and
database records.

I think CommonSQL has a fairly consistent, albeit limited, model. My
first inclination for solving your desired to extend the abilities to
store objects with update-records-from-instance is the following:

Keep the semantics of update-records-from-instance intact. Mostly to
avoid overloading the meaning of the :database key argument, but also
to keep a consistent model that objects are directly tied to a
particular database.

Second, to accomodate your desire to take an object and store in (and
presumably you also want to associate that object with) a different
database, then a new function can be added that explicitly breaks the
existing database-object binding. Something like:

(defun dissociate-instance-from-records (obj)
  (slot-makunbound obj 'view-database))

While adding an extra function call results in a bit longer code for
the client, it does make it explicit in your code that you want a
instance free of its previous database association.

-- 
Kevin Rosenberg
[email protected]