On Sep 4, 2008, at 5:55 PM, Jon wrote:
>
> I'll note that I find building a single query for potentially several
> uses quite handy, whether I'm doing a get() or an additional filter/
> filter_by. By prebuilding as much of the query as possible I reduce
> the overall complexity of my applications, in some cases considerably.
> I've found that I can *usually* get around this issue by making use of
> the order_by in the ORM layer but that doesn't always help, in
> particular when I'm not using get(x).
>
> Often my queries look like this:
> q = dbsess.query(Obj)
> q = q.join('some_relation')
> q = q.order_by(OtherObj.c.columnX)
> q = q.options(eagerload('some_other_relation'))
> q = q.options(eagerload('some_third_relation'))
>
> and then later, often in another function and depending on the input:
>
> instance = q.get(pkey)
> or
> instances = q.all()
> or even
> instances = q.filter(criteria....).all()
>
> Being able to make use of a single base query makes my job much easier
> - in all cases I know ahead of time the relations and ordering I want,
> but in almost every case the function(s) which get the query object
> passed to them *don't* know this stuff - if I have to avoid building
> my queries this way I'll either have to build multiple sets of queries
> (one for get and one for everything else) or move the knowledge
> necessary to do so around quite a bit more.
>
> I'm hoping that by outlining my use case, and the fact that query_by
> doesn't really change the result of a get either way (hey, if I want
> to make an inefficient query...) that I can persuade you to allow the
> use of query_by and get(X).
order_by() in particular easily leads to ambiguous situations for
which we have had users report as bugs, because SQLA was making an
arbitrary choice which disagreed with what those users felt it should
do. In particular, an operation such as:
query.filter(...).limit(2).order_by(criterion)
vs.
query.filter(..).order_by(criterion).limit(2)
Some users feel that both queries should issue: SELECT * FROM table
WHERE <criterion> ORDER BY <criterion> LIMIT 2
Whereas other users feel that the second query only should issue:
SELECT * FROM (SELECT * FROM table WHERE <criterion> LIMIT 2) ORDER BY
<criterion>
Because of scenarios like that, it makes more sense that the Query
would not be a "dumb accumulator" of criteria, and instead would raise
an error when being asked to do something ambiguous or nonsensical.
So we have taken lots of steps to prevent unstructured usage of Query,
which should lead to clearer application code.
In your specific case, I don't see what's so hard about creating a
Query which has *only* those aspects which make sense both to a get()
as well as a join()/order_by() combination (in this case the eagerload
options), and passing that to further functions. The "backwards"
behavior you're looking for, i.e. that a bunch of state set up on
Query would essentially be arbitrarily "ignored", suggests that your
application might be easier to understand if you rearranged it to not
rely upon that behavior.
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
