On Sep 4, 5:43 pm, Michael Bayer <[EMAIL PROTECTED]> wrote:
> 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.
I understand and approve of the motivations.
> 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.
In this case it means a doubling of the number of queries I already
have, and those queries are indexed by name. Since the queries
(sometimes fairly complex) would be almost exactly the same it would
actually make things much harder to understand. Currently, the only
special case I have is whether to use get(X) or filter/filter_by +
all(). However, I'd much rather discuss things from a different
standpoint. Let me rephrase the question - what is /wrong/ (not /
nonsensical/) about combining order_by with get(X)? The only
difference in the SQL generated is, in fact, the ORDER BY which
shouldn't matter.
I guess I'm following the philosophy of: if it doesn't hurt, and it
makes some things easier or clearer, then it's fine. This seems to no
different than bash suddenly proclaiming that "cat FILE | grep ..."
won't work any more because the cat is gratuitous.
One might argue that get(X) itself is superfluous because, hey,
applications might as well just use filter/filter_by and check for > 1
return value themselves.
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to [email protected]
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
-~----------~----~----~----~------~----~------~--~---
