[sqlalchemy] Re: order_by on related object attribute?
On 4/19/07, Michael Bayer [EMAIL PROTECTED] wrote:
On Apr 19, 2007, at 9:39 AM, Gaetan de Menten wrote:
By the way, lately I've been wishing SQLAlchemy would add a column
(and possibly its table) automatically to the select clause if I do an
order by a column which is not in the currently selected columns.
I mean that you could write:
query(System).select(System.c.lastseen self.this.week,
order_by=[client.c.name])
and it would figure out that the client.c.name is not in the
selection, and would add it (or rather would add the join you describe
above).
I would agree up to the point that the table gets added, which is
what happens if you add columns to the SELECT clause of a select; the
table gets appended to the FROM clause.
Good.
but i dont agree in creating
JOIN objects automatically with no explicit specification that that's
whats desired (as usual, i am open to all sorts of explicit methods
of specifications...although we have plenty for specifying join on a
relationship at this point).
the query above I would express generatively as:
query(System).filter(System.c.lastseen self.this.week).order_by
(client.c.name).join('clients').list()
Maybe it would also be handy to have join() accept a Table as well as
a Class argument, and have it figure out the auto-thing in those
cases as well. all that is fine with me (since theres no other
meaning you could get from join(SomeOtherClass) ).
Good too. But would this work in all cases? Even if the class is
mapped several times, mapped to an arbitrary selectable and so on?
cant we just agree that adding the join automatically is an egregious
case of implicit over explicit ?
Yes, you are perfectly right, and I fully agree the autojoin part
was a pretty stupid suggestion.
considering that it is *so*
*easy* to join on a relationship now:
query(MyClass).join('somerelation').select(table2.c.name=='foo')
Yes, [and here I was going to say] but it doesn't solve my order by a
related column as a mapper option problem but then suddenly realized
that what I want is already possible.
Mapping my class against the join between system and client, than
using order_by=client.c.name should work, right? Sorry for the
trouble.
Note that it doesn't change the fact that what you agreed to above
still seem like a good idea.
--
Gaëtan de Menten
http://openhex.org
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
[sqlalchemy] Bug in select/offset limit
I have this piece of code which I came across accidentally: page = 0 limit = '1' # note that one of the above values is a string, and the other a 0 data = ATable.select(a_table.c.id.in_(*aIDs), limit=limit, offset=(page*limit)) Note the * on strings which is resulting in '' Now this query fails because offset part of the query isn't constructed properly. I think the correct behaviour should be to ignore the offset part of the query? I can reproduce on any table on 0.3.6. thanks. -- Ram --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Bug in select/offset limit
On Friday 20 April 2007 16:59:55 Michael Bayer wrote: On Apr 20, 2007, at 5:00 AM, Ram Yalamanchili wrote: I have this piece of code which I came across accidentally: page = 0 limit = '1' # note that one of the above values is a string, and the other a 0 data = ATable.select(a_table.c.id.in_(*aIDs), limit=limit, offset= (page*limit)) Note the * on strings which is resulting in '' Now this query fails because offset part of the query isn't constructed properly. I think the correct behaviour should be to ignore the offset part of the query? you mean, select(..., offset='') , should just ignore the offset. well no, '' is not a valid argument for offset (valid values are None or an integer) so it should raise an error...wouldnt want to ignore that. are strings allowable there at all? e.g. this is like limit='1', offset=''... - limit is also a string. note also the .in_(list_that_can_be_empty) --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Bug in select/offset limit
On Apr 20, 2007, at 5:00 AM, Ram Yalamanchili wrote: I have this piece of code which I came across accidentally: page = 0 limit = '1' # note that one of the above values is a string, and the other a 0 data = ATable.select(a_table.c.id.in_(*aIDs), limit=limit, offset= (page*limit)) Note the * on strings which is resulting in '' Now this query fails because offset part of the query isn't constructed properly. I think the correct behaviour should be to ignore the offset part of the query? you mean, select(..., offset='') , should just ignore the offset. well no, '' is not a valid argument for offset (valid values are None or an integer) so it should raise an error...wouldnt want to ignore that. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Null Foreign key issues
Hi wfpearson, On Apr 18, 1:21 pm, wfpearson [EMAIL PROTECTED] wrote: [snip full description of the problem] I've tried the following method: surgery = session.query(Surgery).select_by(dictation=None)[0] I'm pretty new to all of this myself, but maybe try using clause elements in yout select_by. See: http://www.sqlalchemy.org/docs/datamapping.html#datamapping_query So maybe something like: surgery = session.query(Surgery).select_by(surgery_table.c.dictation_id==null()) [0] would work. This is _totally_ untested (and it might be gibberish), but it might be worth a try. Good Luck, Matthew --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Release posted on homepage!
I noticed current release information is now available on the SQLAlchemy homepage! Good job! Greg --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Bug in select/offset limit
On 4/20/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: On Friday 20 April 2007 16:59:55 Michael Bayer wrote: On Apr 20, 2007, at 5:00 AM, Ram Yalamanchili wrote: I have this piece of code which I came across accidentally: page = 0 limit = '1' # note that one of the above values is a string, and the other a 0 data = ATable.select(a_table.c.id.in_(*aIDs), limit=limit, offset= (page*limit)) Note the * on strings which is resulting in '' Now this query fails because offset part of the query isn't constructed properly. I think the correct behaviour should be to ignore the offset part of the query? you mean, select(..., offset='') , should just ignore the offset. well no, '' is not a valid argument for offset (valid values are None or an integer) so it should raise an error...wouldnt want to ignore that. are strings allowable there at all? e.g. this is like limit='1', offset=''... - limit is also a string. note also the .in_(list_that_can_be_empty) Passing a string in limit or offset does work (atoi done internally i think). Thats the reason I thought offset='' doesn't make sense. Shouldn't there atleast be a better error than trying to figure what is wrong with the sql statement? thanks. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: polymorphic inheritance -- stumped!
Murphy's law strikes again. As soon as I sent the email, I finally noticed that I wasn't passing my table into my outputs_mapper after staring at it for an hour... Sorry for the spam! -- Jonathan LaCour http://cleverdevil.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Null Foreign key issues
First thing I'm doing is rewriting the model and mapper without Elixir. I'm not sure if that was causing the issue or not. This is so frustrating because SQLAlchemy's documentation is so thorough I thought I would be able to solve it on my own. On Apr 20, 2:35 pm, desmaj [EMAIL PROTECTED] wrote: Hi wfpearson, On Apr 18, 1:21 pm, wfpearson [EMAIL PROTECTED] wrote: [snip full description of the problem] I've tried the following method: surgery = session.query(Surgery).select_by(dictation=None)[0] I'm pretty new to all of this myself, but maybe try using clause elements in yout select_by. See:http://www.sqlalchemy.org/docs/datamapping.html#datamapping_query So maybe something like: surgery = session.query(Surgery).select_by(surgery_table.c.dictation_id==null()) [0] would work. This is _totally_ untested (and it might be gibberish), but it might be worth a try. Good Luck, Matthew --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: Bug in select/offset limit
On Apr 20, 2007, at 5:21 PM, Ram Yalamanchili wrote: Passing a string in limit or offset does work (atoi done internally i think). Thats the reason I thought offset='' doesn't make sense. Shouldn't there atleast be a better error than trying to figure what is wrong with the sql statement? sure. but then again, this is python, and to be able to guard against all errors of this kind (i.e., passing the wrong type to a function), would require a huge layer of type assertions on every function everywhere. which i wouldnt want to do, because of the performance overhead, maintenance overhead, code readability overhead, plus the fact thatits python - which provides no standard/easy way of typechecking method arguments...yet we all get our work done anyway. so it feels a little weird that we should have type checks only on methods for no reason other than, someone happened to stumble upon it...can we have a better criterion for which methods get explicit type checks ? other than, all methods ? because that would be alittle unworkable. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups sqlalchemy group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~--~~~~--~~--~--~---
[sqlalchemy] Re: AssociationProxy fails with order_by
On Apr 20, 2007, at 11:14 PM, Paul Kippes wrote:
I had been using an order_by with the AssociationProxy since 0.3.4.
In 0.3.6, this has been broken or else no longer supported. Since
this is an extension, it has no unit tests (is this the norm?)
extensions do have unit tests in some cases, the association proxy
was a real fast idea I had one day, and its also a pretty small set
of code, so it hasnt acquired any as of yet.
The resulting SQL fails with no such column: items.description
this error is not related to the association proxy and is because the
items table is not used to load OrderItem objects, so the OrderItem
eager loader leaves the column alone. there is a line in the 0.3.5
version and earlier that runs the alias step unconditionally on all
the ORDER BY clauses attached to the statement and thats why it works
there...but this was removed because it could affect elements which
the user didnt intend to be lumped into the eager clause for that
relationship.
the appropriate way to set up this ordering is like:
mapper(Order, orders, properties={
'itemassociations':relation(OrderItem, cascade=all, delete-
orphan, lazy=False, order_by=None)
})
mapper(Item, items)
mapper(OrderItem, orderitems, properties={
'item':relation(Item, lazy=False, order_by=items.c.description)
})
the order_by=None on itemassociations is so no ORDER BY clause is
generated for that relationship, allowing the order by on the item
relationship to take effect.
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
sqlalchemy group.
To post to this group, send email to sqlalchemy@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en
-~--~~~~--~~--~--~---
