Re: CLSQL source code repositories

Saurabh Nanda wrote:
> Hmm... hadn't thought of this approach. Wanted to get my stuff working at
> that point of time. So what would the implementation look like:
> 
> 1. Subclass standard-db-class to create extended-db-class (for example).
> 2. Create a  extended-db-object whose metaclass is extended-db-class
> 3. Create a def-extended-view-class macro which ensures that the metaclass
> of the class being defined is extended-db-class

I think it should look like what you what the object to
accomplish. From reading your statement below, it appears that you
want to have an object that contains a sequence/field name so that
a single primary key object can be automatically assigned and stored
with that object.

I think your suggestion below is probably best. But, assuming you want
to have only one sequence name for all objects of that class, the
proper way would be #1 above.

> To give some background about this entire sequences feature: I am very
> influenced from Ruby-on-Rails and their philosophy of convention over
> configuration. So, given that you follow a certain convention in your DB
> design there's a lot of stuff that ActiveRecord (the ORM software that Rails
> uses) can give you a lot of stuff that works like magic.

> If the object was read from a DB it is  updated, else it is inserted (this
> is the way update-records-from-instance works currently). In case the object
> is being inserted in the DB, I look up the sequence name from the metaclass,
> look up the first unbound key slot and assign it the next get the next
> sequence value.

I understand.

> I've modified initialize-instance and reinitialize-instance to compute the
> sequence name as <base-table-name>-SEQ if it's not explicitly specified in
> the def-view-class macro (convention over configuration). So if your base
> table is called employees the associated sequence will be called
> EMPLOYEES_SEQ.

Since the sequence can be opaque, and you'll have only one sequence
per base class, then using a an internal sequence name would
work. Perhaps something like __CLSQLSYS_EMPLOYEES_SEQ__ That would
avoid having the complexity of subclassed view-class object

> Another thing along that line, but different, is the wish of some
> > users to have an high-level mechanism for using an autoincrementing
> > key. On platforms that natively supported such a field, the native
> > atomic autoincrement key would be used. On platforms that don't
> > support it, a CLSQL sequence would be used provide the
> > autoincrementing key (with subsequent greater overhead).
> 
> I didn't understand this completely. I'm using the sequence-next function to
> generate the next sequence value. Does it cover this use case?

No, I'm talking about using sequence-next on db-backends which don't
support autoincrementing keys. But on sql engines that do support
autoincrementing primary keys (like mysql), it is more efficient just
to store the object then ask the db what was the primary key of the
object you stored compared to reading then storing a sequence table
and then storing the object. Plus, with the atomic autoincrementing,
you don't need to lock the table.

> That sounds intriguing. To avoid breaking backward and CommonSQL
> > compatibily, perhaps that function should have a new name like
> > "update-records-deeply-from-instance". Or, add a new keyword like
> > ":deep t" to the existing function to activate the deep storage. I see
> > why an object must have some reference to find its primary key to
> > accomplish this feat. Couldn't the function look at the slots of the
> > view-database to see which is designated as the linking key and use
> > that as the key for the subobjects?
> 
> Not breaking previous functionality is something which I wasn't thinking of
> while getting my job done. I'll rewrite stuff to take this into
> consideration.

Very good. As you might guess for this project that has been ongoing
for 5 years, not breaking things for existing users is of great
importance.

> Performance improvments for find-objects would be great. Personally, I
> > don't use the OODDL/OODML interface. I prefer the straight SQL of
> > FDML. Still, some people do try to fashion an object-oriented DB of a
> > relational DB. But, assuming there is no backwards incompatibility,
> > that sounds like a nice improvement for those who do create
> > hierarchies of objects.
> 
> Heh :-) The debate rages on... but having tasted the Ruby-on-Rails world
> where putting a web based front-end to a DB is so dead simple, I can't stand
> why Lisp doesn't have it.

Simple has its advantages. Typically, I tend to trade that for
flexibility, consistency, and efficiency. If I have an idiom that
needs repeating, I tend to embed that in a function or macro around
the FDML layer.

I did bang my head on the CL ObjectStore library which had a very
simple interface which was also much more powerful that
CommonSQL. But, after 3 schema rewrites and numerous support
conversations with Franz and still getting out-of-memory failures, I
found using CLSQL with FDML gave me a highly efficient, easy to use,
densely-linked 18GB SQL database.

That said, there are some simple one-key tables where automatically
getting it's primary key and storing it in the next primary key in the
in-memory object would cut down on end-user coding and your
modifications would be most welcome.

-- 
Kevin Rosenberg
[email protected]