sqlobject-discuss

[SQLObject] Best way to order columns

[Mark M. <ma...@di...>]

I have two questions:

1) What is the best way force a particular order to the columns returned by 
a select()?

By this I do not mean sorting records - I mean the order of the columns.  
So for a given select(), SQLObject returns the columns in the order they 
appear in the database.  Is there a way to specify a new default in which 
they are returned, or do I have to reorder them myself after I do a 
select()?

2) In terms of sorting records, it appears that when I specify a join, I 
can use the orderBy keyword and pass it a list and it will happily sort the 
items based on the order of the items in the list (at least it appears to 
work that way).  However the _defaultOrder class variable will not take a 
list.  Is there any way to specify more than one parameter to the SQL that 
is generated for the "ORDER BY" clause as the default for select()?

-- 
Thanks,
Mark.

Re: [SQLObject] Best way to order columns

[Ian B. <ia...@co...>]

On Wed, 2003-07-09 at 13:01, Mark Melvin wrote:
> I have two questions:
> 
> 1) What is the best way force a particular order to the columns returned by 
> a select()?
>
> By this I do not mean sorting records - I mean the order of the columns.  
> So for a given select(), SQLObject returns the columns in the order they 
> appear in the database.  Is there a way to specify a new default in which 
> they are returned, or do I have to reorder them myself after I do a 
> select()?

Columns aren't ordered as they are returned -- full objects with
attributes for the columns are returned.

> 2) In terms of sorting records, it appears that when I specify a join, I 
> can use the orderBy keyword and pass it a list and it will happily sort the 
> items based on the order of the items in the list (at least it appears to 
> work that way).  However the _defaultOrder class variable will not take a 
> list.  Is there any way to specify more than one parameter to the SQL that 
> is generated for the "ORDER BY" clause as the default for select()?

There was supposed to be :(  I guess I forgot the last part of
implementing it.  Bad me for not making the right test.  CVS has this
fix.  I think I'll put out a 0.4.1 before too long as well.

  Ian

Re: [SQLObject] Best way to order columns

[Mark M. <ma...@di...>]

On 10 Jul 2003 14:18:07 -0500, Ian Bicking <ia...@co...> wrote:

> On Wed, 2003-07-09 at 13:01, Mark Melvin wrote:
>> I have two questions:
>>
>> 1) What is the best way force a particular order to the columns returned 
>> by a select()?
>>
>> By this I do not mean sorting records - I mean the order of the columns.
>>
>> So for a given select(), SQLObject returns the columns in the order they 
>> appear in the database.  Is there a way to specify a new default in 
>> which they are returned, or do I have to reorder them myself after I do 
>> a select()?
>
> Columns aren't ordered as they are returned -- full objects with
> attributes for the columns are returned.
>

Yes, of course.  Perhaps I am using things in a bad way.  In order to 
generate column labels for a list control I am iterating through the 
SQLObject._columns attribute, pulling out .kw['name'] for each one.  It is 
a list in a particular order, which I assume is used to generate the 
select() statement because the order appears to match.  It does not appear 
to match the order in which the columns are created in my particular class. 
 I guess I should look at the source to see how this _columns list is 
created and go from there.


>> 2) In terms of sorting records, it appears that when I specify a join, I 
>> can use the orderBy keyword and pass it a list and it will happily sort 
>> the items based on the order of the items in the list (at least it 
>> appears to work that way).  However the _defaultOrder class variable 
>> will not take a list.  Is there any way to specify more than one 
>> parameter to the SQL that is generated for the "ORDER BY" clause as the 
>> default for select()?
>
> There was supposed to be :(  I guess I forgot the last part of
> implementing it.  Bad me for not making the right test.  CVS has this
> fix.  I think I'll put out a 0.4.1 before too long as well.
>

Cool.  I have re-architected my LEFT JOINed approach to be a single table 
and I am finding SQLObject pretty sweet.  Simplifying my first case helped 
me a lot to get started, and it should be easier to extend to more 
complicated cases.  I found the documentation - while good, is missing a 
lot of the little things.  I found myself doing a dir() on object a lot to 
figure out what was in there.

At any rate - thanks for a great tool.  It is making this project a lot 
easier.

-- 
Thanks,
Mark.

Re: [SQLObject] Best way to order columns

[Ian B. <ia...@co...>]

On Thu, 2003-07-10 at 14:37, Mark Melvin wrote:
> Yes, of course.  Perhaps I am using things in a bad way.  In order to 
> generate column labels for a list control I am iterating through the 
> SQLObject._columns attribute, pulling out .kw['name'] for each one.  It is 
> a list in a particular order, which I assume is used to generate the 
> select() statement because the order appears to match.  It does not appear 
> to match the order in which the columns are created in my particular class. 
>  I guess I should look at the source to see how this _columns list is 
> created and go from there.

It is probably sorted by the order of the hashes of the strings used to
name the objects, i.e., effectively unsorted.  When you do:

class Something(SQLObject):
    fname = Col()
    lname = Col()

SQLObject (MetaSQLObject to be particular) looks through the classes
*dictionary*, which is of course unordered.  If you want to order them
more naturally, you'll have to add another attribute that contains that
ordering (like order=['fname', 'lname']), or do it alphabetically or
something.

I suppose a slightly hackish solution would be to make Col objects
remember what order they were instantiated in.  I'm not sure if that's
evil or convenient.

> Cool.  I have re-architected my LEFT JOINed approach to be a single table 
> and I am finding SQLObject pretty sweet.  Simplifying my first case helped 
> me a lot to get started, and it should be easier to extend to more 
> complicated cases.  I found the documentation - while good, is missing a 
> lot of the little things.  I found myself doing a dir() on object a lot to 
> figure out what was in there.

A lot of stuff that is not documented is an unstable interface.  You're
welcome to use it of course (I'm a firm opponent of double-underscore
private variables), but be warned it may change.  If there's something
in particular that you think is important, bring it up and perhaps we
can make a stable interface for it.

It sounds like you are doing some introspection, which is something in
particular that I have put off until I have a better feel for how it
should work.

  Ian