I am defining my result list the following way:
result = queryobject.select(mytable.c.columnname == columnname, limit
= maxResults, offset = 0)
maxResults is the number of records I want returned. In case I want
all the records, I am setting maxResults as -1. However, this is not
working for
default of limit is None.
All those query.select arguments go in a orm.query.QueryContext()
do see its __init__ for which arg has what default.
On Tuesday 17 April 2007 09:31:04 Disrupt07 wrote:
I am defining my result list the following way:
result = queryobject.select(mytable.c.columnname
attached is an approach that uses just the tiniest amount of
awareness of how a mapper works, to do the whole optimized loading
scenario ahead of time, and you get an object with your two distinct
pro and con relationships, no list decoration or anything
needed. the appropriateness of
On 4/17/07, Michael Bayer [EMAIL PROTECTED] wrote:
On Apr 10, 2007, at 10:22 AM, Gaetan de Menten wrote:
By the way, should I create a ticket for this?
ive created ticket #541 for this,
I had already created ticket #531 for this. Sorry for not mentioning
it here (I thought you'd see it).
On Apr 17, 2007, at 2:49 PM, Gaetan de Menten wrote:
I had already created ticket #531 for this. Sorry for not mentioning
it here (I thought you'd see it). Anyway, it can be closed too now :).
oh crap, sorry, i did a quick search thru track for filtered and
nothing came up. yeah im
Michael wrote:
attached is an approach that uses just the tiniest amount of
awareness of how a mapper works, to do the whole optimized
loading scenario ahead of time, and you get an object with your
two distinct pro and con relationships, no list decoration
or anything needed. the
On Apr 17, 2007, at 3:19 PM, jason kirtland wrote:
Michael wrote:
attached is an approach that uses just the tiniest amount of
awareness of how a mapper works, to do the whole optimized
loading scenario ahead of time, and you get an object with your
two distinct pro and con
I'm not sure why. But when I do a delete/sql alchemy seems to be
running the save/delete operation twice. Could this be related to a
circular dependency in UOW that is undetected?? When deleting this is
causing the following error because the database delete is done twice:
send me a reproducing test case, or at least let me see your
mappings. in particular, dont mix a mapping on a table that is also
used as secondary in a many-to-many relationship.
On Apr 17, 2007, at 5:47 PM, chris e wrote:
I'm not sure why. But when I do a delete/sql alchemy seems to be