|
From: Oleg B. <ph...@ph...> - 2011-02-14 08:39:06
|
On Mon, Feb 14, 2011 at 11:26:47AM +0300, Oleg Broytman wrote:
> On Mon, Feb 14, 2011 at 09:08:57AM +0100, Daniel Fetchinson wrote:
> > >> Now that we are at it I was wondering whether
> > >> something similar could be adopted for tables too. The order in which
> > >> the tables are defined, class table1( SQLObject ), class table2(
> > >> SQLObject ), etc, etc, could also be significant and one might want to
> > >> remember this ordering. And since there is all sorts of metaclass
> > >> trickery involved with class creation, maybe the ordering could be
> > >> stored.
> > >>
> > >> What do you think?
> > >
> > > Yes, it could be done in a metaclass or in the constructor.
> >
> > As far as I can see declarative.DeclarativeMeta is the place to look.
> > I'll try to come up with something.
>
> DeclarativeMeta is a generic metaclass. SQLObject-specific metaclass
> should become its descendant. I suppose you don't need to have
> .creationOrder attribute in all classes (sqlmeta?)
> If you only need .creationOrder in SQLObject classes (tables) it's
> enough to set it in __init__, right before testing for
> _SO_fetch_no_create.
> Actually I started to think .creationOrder if the tables is not that
> interesting because it depends on the order of import. The order of
> columns is more interesting and more stable.
Oops, dammit, a classical wrong way of thinking. __init__ is about
creating *rows*, and you certainly is thinking about *classes*. So the
only right way to go is a metaclass.
Oleg.
--
Oleg Broytman http://phdru.name/ ph...@ph...
Programmers don't die, they just GOSUB without RETURN.
|
