Re: [SQLObject] Using SQLObjects as Abstract Classes

[Brad B. <br...@bb...>]

On Fri, Jul 25, 2003 at 11:08:36AM -0500, Ian Bicking wrote:
> On Fri, 2003-07-25 at 08:22, Brad Bollenbach wrote:
> > On Thu, Jul 24, 2003 at 08:57:19PM -0500, Ian Bicking wrote:
> > > On Thu, 2003-07-24 at 14:42, Brad Bollenbach wrote:
> > > > Hi all,
> > > > 
> > > > How can I use an SQLObject-derived class as an abstract base class?
> > > 
> > > Hmm... I'm not exactly clear what an abstract base class is.  Is there a
> > > particular problem you are trying to solve?
> > 
> > An abstract base class is a class that's not intended to be directly
> > instantiated, instead defining methods that are intended to be
> > overridden in derived classes.
> 
> Oh, right right, I don't know why the terminology was confusing me.
> 
> You'll have to do something like:
> 
> class MonitorBase:
>     ...
> 
> class Monitor(SQLObject, MonitorBase):
>     ...

This still doesn't solve the problem though. I would have to do it
more like:

class StatusMonitor(SQLObject, MonitorBase)

class KeywordMonitor(SQLObject, MonitorBase)

etc

(which still doesn't quite work, because I'm getting separate tables
for each, which I don't want)

Eeek.

> > The problem I'm trying to solve is a web monitoring system:
> > 
> > MonitorBase
> >      | | |
> >      | | -> StatusMonitor
> >      |  --> KeywordMonitor
> >       ----> MD5ChecksumMonitor

[snip] 

> If you have that class layout, you are supposing that there will be
> other subclasses of Monitor.  However, each of these subclasses must be
> a separate table, or great confusion will ensue.

There will only be a single monitor table. Monitors store a common set
of properties. The only thing that's different is how they behave when
you say "do your monitor check".

> Python inheritance simply doesn't map to RDBMS tables.  There are things
> that can be called inheritance among RDBMS tables, but they aren't the
> same thing.  So SQLObject just takes a one-class-one-table approach. 
> You can still use inheritance, and a class can be abstract so long as
> you don't use it, but it's still one-class-one-table.  It's improper to
> use _table = 'monitor' in each class, because that breaks that rule.  If
> you have one table you shouldn't have more than one class that you use
> with that table.

Hrmph.

I can see where you're coming from, but perhaps some thought could be
spent on figuring out how to make that "one class" (per table) be an
abstract class (so, I kind of really only do have class per table,
because StatusMonitor, KeywordMonitor, etc are just there to specify
differences in behaviour, not in attributes. That "one class" is my
abstract base.)

FWIW, the architecture of this app may change so that each monitor has
its own table (/maybe/), but in any case, I can see many uses for
abstract base SQLObjects.

What do you guys think about using abstracts as SQLObjects? Can there
be a solution?

--
Brad Bollenbach
BBnet.ca