Re: [SQLObject] two beginner's questions

[Ian B. <ia...@co...>]

On Mon, 2003-04-28 at 23:33, Luke Opperman wrote:
> So. To elaborate. You can either define your common column type as a
> subclass of Col (or StringCol, etc). Or you can use SQLObject
> inheritance with a structure like:
> 
> class AbstractObject(SQLObject):
>     _columns = StringCol('lang')
> 
> class Z(AbstractObject):
>     _columns = AbstractObject._columns + [StringCol('nother')]
> 
> class Y(AbstractObject):
>     _columns = AbstractObject._columns + [StringCol('further')]
> 
> And all of this actually seems to work in SQLObject 0.3, tested using
> DBMConnection. Wow. What do you say to that, Nick? :)
> 
> - Luke
> 
> P.S. I'm still tracking down the problem with CVS, but it initially
> appears to be related to _SO_plainSetters and addColumn. Just a heads
> up, Ian.

Okay, I think I figured out what the problem is, but not the solution.

Column objects are bound to the class they are used with.  During class
initialization, Col.setClass gets called, with the class argument.  At
that point some fixing up occurs -- new with 0.4, for instance, you can
do:

class Z(SQLObject):
    nother = StringCol()

After instantiation the StringCol object is given its name, and only
then can it set some things like .dbName.  Style information also comes
into play at that point.

So I'm not sure... I guess to fix this the original column definition
has to be left alone, and the column object needs to be cloned by
MetaSQLObject and then tied to the class.  Arr... that's a pain.  I do
want subclassing to be possible, though (and with the new way of
defining columns it should be more pleasant to use).

  Ian