sqlobject-discuss Mailing List for SQLObject (Page 30)

On 16 February 2011 17:05, Oleg Broytman <ph...@ph...> wrote:
>   If SVNDocument is actually Document in this example, and type to
> filter must be compared equal to DocumentType.dbType

Ah yes, sorry about those errors.

>    docs.filter(
>        (Document.q.dbDocumentTypeID==DocumentType.q.id) &
>        (DocumentType.q.dbType==type)
>    )

I still can't get this to work — even if I set "type" to something
that doesn't match anything in the table, the filter has no effect —
the count of results is the same before and after, when I'd expect it
to be zero for a type not in the table. (I've checked that it goes
through that "if", too.)

I also changed the dbDocumentTypeID to dbDocumentType with no luck
(what's the difference between the two? I notice the same naming
change in the j-magic section of the docs).

One of the other things I tried is to use a j-magic expression:
Document.j.dbDocumentType & (DocumentType.q.dbType==type) ... but
still nothing happens to the select result. I've been trying to
construct an "IN" query, but haven't really gotten anywhere with that
yet either.

Any other suggestions?

Cheers,
Jason

On Wed, Feb 16, 2011 at 02:10:41AM -0800, Sam's Lists wrote:
> Are there any plans to change that?

   There is no just because this is the first time the question is
raised. I've added it to the TODO list:
http://sourceforge.net/mailarchive/forum.php?thread_name=E1PnpY6-00009p-IX%40webwareforpython.org&forum_name=sqlobject-cvs

> I assume it's a pretty complicated change, right?

   At the first glance it seems one needs to change SOForeignKey (and
perhaps SOCol), sqlmeta.add/delColumn(); SQLObject._SO_foreignKey() must
take into account the id could be any column, not only an id; the
current code could be preserved as a shortcut in case otherColumn is id.

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

I see.

Are there any plans to change that?

I assume it's a pretty complicated change, right?

-Sam

On Fri, Feb 11, 2011 at 1:05 AM, Oleg Broytman <ph...@ph...> wrote:

> On Thu, Feb 10, 2011 at 10:24:43PM -0800, Sam's Lists wrote:
> > I'd like to have a foreign key use a unique column in another table which
> is
> > not the primary key.  This works fine in Postgres, but I can't figure out
> > how to do it in SQLObject.  Any idea?
>
>    SQLObject can only references an 'id' column. That's, probably, a
> deficiency.
>
> Oleg.
> --
>     Oleg Broytman            http://phdru.name/            ph...@ph...
>           Programmers don't die, they just GOSUB without RETURN.
>
>
> ------------------------------------------------------------------------------
> The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
> Pinpoint memory and threading errors before they happen.
> Find and fix more than 250 security defects in the development cycle.
> Locate bottlenecks in serial and parallel code that limit performance.
> http://p.sf.net/sfu/intel-dev2devfeb
> _______________________________________________
> sqlobject-discuss mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss
>

Hi!

On Wed, Feb 16, 2011 at 02:20:33PM +0800, Jason Heeris wrote:
> I'm trying to filter a selection from one table by looking up a
> referenced value in another table. An example is probably the easiest
> explanation:
> 
> ----
> class DocumentType (SQLObject) :
>     """ What type the document is assigned to.
>     """
>     dbType = StringCol()
> 
> class Document (SQLObject) :
>     """ Location of stored documents
>     """
>     dbPath = StringCol()
>     dbDocumentType = ForeignKey('DocumentType')
> 
> def DocumentSearch(text, type=None):
> 
>     # initial query with text
>     docs = dbase.dbase.SVNDocument.select(...)
> 
>     if type:
>         docs.filter(...)
> 
>     return list(docs)
> ----
> 
> The "docs.filter(...): is where I want to allow only those Documents
> whose dbDocumentType refers to the DocumentType with dbType == type. I
> know this must be simple, but it's been a while since I used SQLObject
> and I just can't see it.

   If SVNDocument is actually Document in this example, and type to
filter must be compared equal to DocumentType.dbType, then filter
should be something like this:

    docs.filter(
        (Document.q.dbDocumentTypeID==DocumentType.q.id) &
        (DocumentType.q.dbType==type)
    )

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

I'm trying to filter a selection from one table by looking up a
referenced value in another table. An example is probably the easiest
explanation:

----
class DocumentType (SQLObject) :
    """ What type the document is assigned to.
    """
    dbType = StringCol()

class Document (SQLObject) :
    """ Location of stored documents
    """
    dbPath = StringCol()
    dbDocumentType = ForeignKey('DocumentType')

def DocumentSearch(text, type=None):

    # initial query with text
    docs = dbase.dbase.SVNDocument.select(...)

    if type:
        docs.filter(...)

    return list(docs)
----

The "docs.filter(...): is where I want to allow only those Documents
whose dbDocumentType refers to the DocumentType with dbType == type. I
know this must be simple, but it's been a while since I used SQLObject
and I just can't see it.

Cheers,
Jason

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

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

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

> >
> > 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: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/            ph...@ph...
           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.
>> >
>> >    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

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

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

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

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

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

What would be the most natural way of specifying an ordering for columns?

I'm not looking for ordering the result of a query but defining an
ordering for the columns at the time of defining class mytable(
SQLObject ). This would be some kind of metadata I'd like to store
with each class. For example, the order in which each column is
defined would be a good way of doing it:

class mytable( SQLObject ):
    first = StringCol( )
    second = StringCol( )
    third = StringCol( )

But how do I make mytable remember this order?

The reason I need this is that I'm developing a database viewer (each
table will be shown as a grid) and I'd like to have a simple way of
defining the order of the columns that should appear in the grid.

Any ideas?

Cheers,
Daniel


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