SQLObject

On Sat, Feb 12, 2011 at 11:53:46PM +0100, Daniel Fetchinson wrote:
> What would be the most natural way of specifying an ordering for columns?

   SQLObject preserves the order of columns, indices and joins since at
least version 0.14.0; the order of every object is stored in the
attribute .creationOrder. Lists of columns (sqlmeta.columnList), indices
(sqlmeta.indexes and sqlmeta.indexDefinitions) and join definitions
(sqlmeta.joinDefinitions) are sorted according to .creationOrder; the
list of joins (sqlmeta.joins) is not sorted due to the way joins are
created.

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            phd@...
           Programmers don't die, they just GOSUB without RETURN.

>> What would be the most natural way of specifying an ordering for columns?
>
>    SQLObject preserves the order of columns, indices and joins since at
> least version 0.14.0; the order of every object is stored in the
> attribute .creationOrder. Lists of columns (sqlmeta.columnList), indices
> (sqlmeta.indexes and sqlmeta.indexDefinitions) and join definitions
> (sqlmeta.joinDefinitions) are sorted according to .creationOrder; the
> list of joins (sqlmeta.joins) is not sorted due to the way joins are
> created.

Great, thank you very much, I did not know about this feature!

Cheers,
Daniel

-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown

On Sun, Feb 13, 2011 at 11:59:40AM +0100, Daniel Fetchinson wrote:
> >> What would be the most natural way of specifying an ordering for columns?
> >
> >    SQLObject preserves the order of columns, indices and joins since at
> > least version 0.14.0; the order of every object is stored in the
> > attribute .creationOrder. Lists of columns (sqlmeta.columnList), indices
> > (sqlmeta.indexes and sqlmeta.indexDefinitions) and join definitions
> > (sqlmeta.joinDefinitions) are sorted according to .creationOrder; the
> > list of joins (sqlmeta.joins) is not sorted due to the way joins are
> > created.
> 
> Great, thank you very much, I did not know about this feature!

   Most of it was implemented by Ian Bicking long before me. At version
0.14.0 I completed it, extended to indices and joins and added to News:

http://sqlobject.org/News.html#sqlobject-0-14-0

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            phd@...
           Programmers don't die, they just GOSUB without RETURN.

>> >> What would be the most natural way of specifying an ordering for
>> >> columns?
>> >
>> >    SQLObject preserves the order of columns, indices and joins since at
>> > least version 0.14.0; the order of every object is stored in the
>> > attribute .creationOrder. Lists of columns (sqlmeta.columnList), indices
>> > (sqlmeta.indexes and sqlmeta.indexDefinitions) and join definitions
>> > (sqlmeta.joinDefinitions) are sorted according to .creationOrder; the
>> > list of joins (sqlmeta.joins) is not sorted due to the way joins are
>> > created.
>>
>> Great, thank you very much, I did not know about this feature!
>
>    Most of it was implemented by Ian Bicking long before me. At version
> 0.14.0 I completed it, extended to indices and joins and added to News:
>
> http://sqlobject.org/News.html#sqlobject-0-14-0

I see, I missed it. 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?

Cheers,
Daniel


-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown

On Sun, Feb 13, 2011 at 03:11:14PM +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.

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            phd@...
           Programmers don't die, they just GOSUB without RETURN.

>> 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.

Cheers,
Daniel



-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown

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.

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            phd@...
           Programmers don't die, they just GOSUB without RETURN.

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/            phd@...
           Programmers don't die, they just GOSUB without RETURN.

Am Mon, 14 Feb 2011 11:38:57 +0300
schrieb Oleg Broytman <phd@...>:

> 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.
> 

I've done a similar thing for other classes (not SQLObject) with
DeklaraticeMeta from SQLObject:

classnr = 0

class Base(object):
    __metaclass__ = declarative.DeclarativeMeta
    def __classinit__(cls, newattrs):
        log.debug("%s.__classinit__" % cls)
        global classnr
        classnr = classnr + 1

--
Greg

On Mon, Feb 14, 2011 at 09:58:24AM +0100, Gregor Horvath wrote:
> >    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.
> 
> I've done a similar thing for other classes (not SQLObject) with
> DeklaraticeMeta from SQLObject:
> 
> classnr = 0
> 
> class Base(object):
>     __metaclass__ = declarative.DeclarativeMeta
>     def __classinit__(cls, newattrs):
>         log.debug("%s.__classinit__" % cls)
>         global classnr
>         classnr = classnr + 1

   __classinit__, but of course! Thank you for reminding!

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            phd@...
           Programmers don't die, they just GOSUB without RETURN.

>> >> 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.
>
>    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.

You mean that somebody might define his/her tables in several files?
That's certainly a possibility.

I always define my tables in a single file and the order in which they
are defined in that particular file is usually relevant (most
important tables come first, related ones come after each other, etc).
So I thought this information could be usefully stored. But you are
right it's not a robust thing if someone defines tables in various
files in which case creation order will depend on the order of
importing.

Cheers,
Daniel


-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown

>>> >> 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?)

Yes, you are right, I'll probably need to subclass DeclarativeMeta,
add the creationOrder in this subclassed metaclass and use this
sublassed metaclass for SQLObject only.

Cheers,
Daniel


-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown

>> > > >> 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.
>>
>
> I've done a similar thing for other classes (not SQLObject) with
> DeklaraticeMeta from SQLObject:
>
> classnr = 0
>
> class Base(object):
>     __metaclass__ = declarative.DeclarativeMeta
>     def __classinit__(cls, newattrs):
>         log.debug("%s.__classinit__" % cls)
>         global classnr
>         classnr = classnr + 1

Sounds good, thanks! There is no global locking issue we need to worry
about, right? I mean there is this global variable classnr.....

Cheers,
Daniel


-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown

On Mon, Feb 14, 2011 at 11:18:51AM +0100, Daniel Fetchinson wrote:
> >    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.
> 
> You mean that somebody might define his/her tables in several files?

   Yes, I do it for bigger database - I split tables into files by their
logical relations.

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            phd@...
           Programmers don't die, they just GOSUB without RETURN.

Am Mon, 14 Feb 2011 11:23:10 +0100
schrieb Daniel Fetchinson <fetchinson@...>:

> >
> > I've done a similar thing for other classes (not SQLObject) with
> > DeklaraticeMeta from SQLObject:
> >
> > classnr = 0
> >
> > class Base(object):
> >     __metaclass__ = declarative.DeclarativeMeta
> >     def __classinit__(cls, newattrs):
> >         log.debug("%s.__classinit__" % cls)
> >         global classnr
> >         classnr = classnr + 1
> 
> Sounds good, thanks! There is no global locking issue we need to worry
> about, right? I mean there is this global variable classnr.....
> 

In my case the class creation is strictly serial, no
parallelism.
I am no expert in SQLObjects internals, but I think the class creation
of SQLObjects is also serial.

I know global smells, but I am pragmatic...

--
Greg

On Mon, Feb 14, 2011 at 11:23:10AM +0100, Daniel Fetchinson wrote:
> > classnr = 0
> >
> > class Base(object):
> >     __metaclass__ = declarative.DeclarativeMeta
> >     def __classinit__(cls, newattrs):
> >         log.debug("%s.__classinit__" % cls)
> >         global classnr
> >         classnr = classnr + 1
> 
> Sounds good, thanks! There is no global locking issue we need to worry
> about, right? I mean there is this global variable classnr.....

   Of course there is. But if you look into the current code, it uses
itertools.count() which, I believe, is thread-safe.

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            phd@...
           Programmers don't die, they just GOSUB without RETURN.

On Mon, Feb 14, 2011 at 01:38:59PM +0300, Oleg Broytman wrote:
> itertools.count() which, I believe, is thread-safe.

   On the other hand don't count on my words - Python documentation
doesn't say anything about thread-safety of itertools.

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            phd@...
           Programmers don't die, they just GOSUB without RETURN.

>> itertools.count() which, I believe, is thread-safe.
>
>    On the other hand don't count on my words - Python documentation
> doesn't say anything about thread-safety of itertools.

In any case since itertools.count is already used in Declarative, I
guess there is no harm using it for an SQLObject-specific
DeclarativeMeta (I mean another instance of it of course).

Cheers,
Daniel

-- 
Psss, psss, put it down! - http://www.cafepress.com/putitdown

On Mon, Feb 14, 2011 at 12:36:03PM +0100, Daniel Fetchinson wrote:
> In any case since itertools.count is already used in Declarative, I
> guess there is no harm using it for an SQLObject-specific
> DeclarativeMeta (I mean another instance of it of course).

   You may reuse it if you don't need strict (+1) monotonicity.

Oleg.
-- 
     Oleg Broytman            http://phdru.name/            phd@...
           Programmers don't die, they just GOSUB without RETURN.