OK, I just checked in something that should be *closer* to what you
want. This gives you greater control over the order_by clause
inserted by a mapper.
1. When you make a mapper, you can specify the ordering it should do
by default. This order_by will replace the normal "oid" based
ordering when specified as a non "False" value.
# order by a column
m = mapper(class, table, order_by=[desc(table.c.col1)]
# dont do any ordering
m = mapper(class, table, order_by=None)
2. When you call select() on a mapper, which ultimately calls
_compile, _compile will look at the order_by on the given statement
and if one has been specified, will disable the default order_by
normally generated by the mapper:
# order by a column
l = m.select(order_by=[asc(table.c.col1)])
# override all ordering with a blank entry
l = m.select(order_by=[])
3. When you have an order_by specified as the default ordering of a
lazy loader, this order_by will be specified to the mapper's select()
method and will override the default ordering used by the mapper.
4. For eager loading, right now the order_by's used by the eager load
are created at the tail end of the _compile method, so the behavior
of them should not change; the ordering of the eagerly-loaded
properties is separate from the ordering of the parent table rows.
let me know if this fixes your issue. If i didnt get it right, it
was a 10 minute change so no big deal....
- mike
On Dec 9, 2005, at 8:25 PM, Robert Leftwich wrote:
The closed ticket #10, says "the parent Mapper still always adds an
"order by <maintable>.oid" type of thing to insure parent object
order. my only concern about that is it might add a performance hit
to a query, and its not really needed in a lazyload."
Well, I can verify that it does take a performance hit when using a
desc(col) , mainly as it stops the db using the 'col' index if
defined, i.e. the sql ends up as '... ORDER BY table.foo DESC,
table.oid', which, in Postgres at least, results in the query
optimizer not using any indexes.
What scope is there for changing this? One possibility is to add
DESC to the oid as well, which would at least let the optimizer
select a (foo, oid) index. Can the order by OID be removed
completely and the sort for parent object order moved into python?
Robert
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through
log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD
SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Sqlalchemy-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Sqlalchemy-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sqlalchemy-users
