Thread: [SQLObject] _defaultOrder with Joins: bug?
SQLObject is a Python ORM.
Brought to you by:
ianbicking,
phd
From: Frank B. <fb...@fo...> - 2003-04-09 21:46:46
Attachments:
fragen.py
|
Hallo, I found, that the _defaultOrder magic attribute doesn't work correctly with joined tables ("QueryAll"-queries). In the attached example (which is a bit confuse, but it's me getting comfortable with joins in SO), the two last operations give different kinds of order for the Answer-table, which should be ordered with a defaultOrder on field "position". ciao -- Frank Barknecht _ ______footils.org__ |
From: Luke O. <lu...@me...> - 2003-04-10 01:42:20
|
Yep, I never submitted my (possibly ugly) patch for this from when I made the suggestion. Here's the sticky part: SQLObject's join's don't actually do an SQL JOIN, they just get Ids. So there's no easy way to just add an "ORDER BY" clause into the SQL code. It's going to come down to speed one way or another, so it may be worthwhile to make them do full JOINs, but here's the fix for the least amount of code change: Just sort the list of objects after you instantiate them. In each Join's performJoin function, return [cls(id) for (id,) in ids] becomes objs = [cls(id) for (id,) in ids] if cls._defaultOrder: order = cls._defaultOrder objs.sort(lambda x,y: cmp(getattr(x, order), getattr(y, order))) return objs Take it or leave it, but it's working pleasantly enough for us. - Luke Quoting Frank Barknecht <fb...@fo...>: > Hallo, > > I found, that the _defaultOrder magic attribute doesn't > work correctly > with joined tables ("QueryAll"-queries). In the attached > example > (which is a bit confuse, but it's me getting comfortable > with joins in > SO), the two last operations give different kinds of > order for the > Answer-table, which should be ordered with a defaultOrder > on field > "position". > > ciao > -- > Frank Barknecht _ > ______footils.org__ > -- Many people are hamstrung by things like affection for fellow employees, honesty, desire to appear to be a "nice person," and other crippling limitations not suffered by the truly powerful and successful. |
From: Ian B. <ia...@co...> - 2003-04-10 04:52:57
|
On Wed, 2003-04-09 at 20:28, Luke Opperman wrote: > Yep, I never submitted my (possibly ugly) patch for this > from when I made the suggestion. Here's the sticky part: > SQLObject's join's don't actually do an SQL JOIN, they just > get Ids. Again based on my familiarity with MySQL, which doesn't have real foreign keys. If you can suggest the changes, to the SQL in particular, that would be good. Well, I should probably just read up on it, since I'm starting to use Postgres more myself. > So there's no easy way to just add an "ORDER BY" > clause into the SQL code. It's going to come down to speed > one way or another, so it may be worthwhile to make them do > full JOINs, but here's the fix for the least amount of code > change: Just sort the list of objects after you instantiate > them. In each Join's performJoin function, > > return [cls(id) for (id,) in ids] > > becomes > > objs = [cls(id) for (id,) in ids] > if cls._defaultOrder: > order = cls._defaultOrder > objs.sort(lambda x,y: cmp(getattr(x, order), > getattr(y, order))) > return objs Really this should be changed to do a more complete SELECT, as I'm doing with .select results (it fetches not just IDs, but also column values). This code precedes that change. Once you are fetching the entire object, it should be relatively easy to do ORDER BY in the SQL, rather than after the fact. Ian |