Re: [SQLObject] two beginner's questions

[Bud P. B. <bu...@si...>]

The good thing about time differences is that you get back to work and
the problem is solved and digested...

Many thanks for all the interesting answers. I particularly like the
one below.  I assume that this should work also in upcoming
versions...

--b



On Mon, 28 Apr 2003 23:33:34 -0500
Luke Opperman <lu...@me...> wrote:

> 
> > 2. is there a way to control redundancy in the following example:
> >
> > class test1 (SQLObject):
> >   _columns = [StringCol("lang", lenght=2, default='en'),
> >               IntCol("someOtherStuffHere")]
> >
> > class test2 (SQLObject):
> >   _columns = [StringCol("lang", lenght=2, default='en'),
> >               StringCol("differentStuffThanInTest1")]
> >
> > I would like to decide only once how to represent a language in the
> > DBMS and use this consistently in various class definitions.
> >
> > I unsuccessfully tried to define a StringCol object, langCol,
> 
> I know we're getting caught up in all sorts of things tangentially
> related (I'm currently in the midst of figuring out why making an
> abstract class with columns and then saying _columns = Super._columns
> + [] doesn't quite work...)
> 
> But there is a somewhat simple non-SQLObject-inheritance-based way to
> get what you want, without the foreign table suggested by Frank.
> Rather than define a StringCol object, define a LangCol *class* which
> is a subclass of StringCol. Something like this ought to work:
> 
> class LangCol(StringCol):
>     def __init__(self, **kw):
>         kw['length'] = 2
>         kw['default'] = 'en'
>         StringCol.__init__(self, 'lang', **kw)
> 
> Yep, just tested this out. Actually, just tested my example above with
> Super._columns, and it works too! (Using 3.0. All classes currently
> have a problem with CVS checked out 10 minutes ago, which was
> throwing me off.)
> 
> 
> 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.
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> sqlobject-discuss mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
> 


/-----------------------------------------------------------------
| Bud P. Bruegger, Ph.D. 
| Sistema (www.sistema.it)
| Via U. Bassi, 54
| 58100 Grosseto, Italy
| +39-0564-411682 (voice and fax)
\-----------------------------------------------------------------