[sqlalchemy] Re: bug? order_by + get(some_id) results in InvalidRequestError
the issue is resolved in r5088. a special exception is made for the specific combination of "q.order_by().get()". ORDER BY is still dropped from the resulting SQL. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: bug? order_by + get(some_id) results in InvalidRequestError
On Sep 6, 2008, at 7:35 AM, Kyle Schaffrick wrote:
> I imagine using the "ambiguous" discriminator instead of "nonsensical"
> might partition the various other query criteria a bit differently as
> well, but in my present state of mental capacity, order_by() is the
> only
> one I can think of that this applies to :)
To make this very specific, here is the method we're talking about:
def __no_criterion_condition(self, meth):
if self._criterion or self._statement or self._from_obj or \
self._limit is not None or self._offset is not None
or \
self._group_by or self._order_by:
raise sa_exc.InvalidRequestError("Query.%s() being called
on a Query with existing criterion. " % meth)
self._statement = self._criterion = self._from_obj = None
self._order_by = self._group_by = self._distinct = False
self.__joined_tables = {}
This method is used by a few methods which do need to raise if
order_by() is set, since order_by() would not normally be a noop in
those cases but existing order_by's are incompatible with the
generative method being called - these are with_polymorphic() and
select_from(), both of which affect aliasing behavior which isnt
retroactively applied to existing state (which isn't for any huge
reason except to limit implementation/test coverage burden).
It is also used by "from_statement()", which is another one of those
methods where we could just blow away all the above without
raising.(no plans for that at the moment).
So for the very specific case of get(), we'd provide a new version of
the above method which does everything the same, except doesn't raise
for "order_by".it seems like "distinct" is also silently dropped.
The fact that its so slightly different is what makes it seem
suspicious on the implementation side. But I'll certainly go with
what appears to be consensus.
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[sqlalchemy] Re: bug? order_by + get(some_id) results in InvalidRequestError
the order_by set on the mapper() is stripped out when using get() with
0.5:
import sqlalchemy as sa
import sqlalchemy.orm as orm
from sqlalchemy.ext.declarative import declarative_base
import StringIO
import logging
buf = StringIO.StringIO()
logging.basicConfig(stream=buf, format = '%(message)s')
logging.getLogger('sqlalchemy.engine').setLevel(logging.INFO)
Base = declarative_base(engine=sa.create_engine('sqlite://'))
class Foo(Base):
__tablename__ = 'foo'
id = sa.Column(sa.Integer, primary_key=True)
data = sa.Column(sa.String)
__mapper_args__ = {'order_by':data}
Base.metadata.create_all()
sess = orm.create_session()
buf.truncate(0)
sess.query(Foo).filter(Foo.id==5).all()
assert "ORDER BY foo.data" in buf.getvalue()
buf.truncate(0)
sess.query(Foo).get(5)
assert "ORDER BY" not in buf.getvalue()
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[sqlalchemy] Re: bug? order_by + get(some_id) results in InvalidRequestError
> > 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. > > get() actually has an explicit line that erases the "order_by" even > if one is present. 0.4 should be doing that but i havent checked > lately if thats covered. in 0.5 the mapper-level order_by() > happens differently so I know why it might not be working > (suggesting its not covered either). > > > 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. > > I'd like to hear what other folks have to say since 0.4's query had > this attitude - you could have filter(), order_by(), whatever you > want set up, and get() would just ignore all that and do its thing. > There was general agreement that this was too open ended. In > this case I dont see order_by() as different from the others; > theyre all things that get() just ignores (or complains about). isn't .count() in the same train? will it complain if it had order_by? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: bug? order_by + get(some_id) results in InvalidRequestError
On Sep 4, 7:01 pm, Michael Bayer <[EMAIL PROTECTED]> wrote: > > 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(). > > im curious, since a Query is pretty much tied to a Session, how is > that working in your application ? Is it using just a single long- > running session ? I create and destroy (close, actually) a session for each request. Essentially, at the beginning of a request the base query for each type of object is built and then passed around quite a bit. From a certain perspective, it's entirely serial as the only state is that which is passed around rather than stored somewhere. > > 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. > > get() actually has an explicit line that erases the "order_by" even if > one is present. 0.4 should be doing that but i havent checked lately > if thats covered. in 0.5 the mapper-level order_by() happens > differently so I know why it might not be working (suggesting its not > covered either). When /not/ using get: 0.4.6 and 0.5b3 are both passing the order by /specified at the ORM layer/ through. I'm talking about when defining the mapper I specify an order_by, *not* when I'm building the query. When using get: 0.4.6 appears to strip the order_by (when specified by the query) on get, although the order_by specified in the mapper remains. 0.5b3 grumps, of course. > I'd like to hear what other folks have to say since 0.4's query had > this attitude - you could have filter(), order_by(), whatever you want > set up, and get() would just ignore all that and do its thing. There > was general agreement that this was too open ended. In this case I > dont see order_by() as different from the others; theyre all things > that get() just ignores (or complains about). For filter and such, yes, I can see that as very confusing - I've specified conditions which should determine the final result but they don't. On the other hand, order_by (and probably some others) are such that they do /not/ alter the final result. > > 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. > > get() does have a different behavioral contract since it can locate > directly from the Session if present. I did not know that. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: bug? order_by + get(some_id) results in InvalidRequestError
On Sep 4, 2008, at 7:19 PM, Jon wrote: > >> 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(). im curious, since a Query is pretty much tied to a Session, how is that working in your application ? Is it using just a single long- running session ? > 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. get() actually has an explicit line that erases the "order_by" even if one is present. 0.4 should be doing that but i havent checked lately if thats covered. in 0.5 the mapper-level order_by() happens differently so I know why it might not be working (suggesting its not covered either). > 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. I'd like to hear what other folks have to say since 0.4's query had this attitude - you could have filter(), order_by(), whatever you want set up, and get() would just ignore all that and do its thing. There was general agreement that this was too open ended. In this case I dont see order_by() as different from the others; theyre all things that get() just ignores (or complains about). > 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. get() does have a different behavioral contract since it can locate directly from the Session if present. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: bug? order_by + get(some_id) results in InvalidRequestError
On Sep 4, 5:54 pm, Michael Bayer <[EMAIL PROTECTED]> wrote: > as usual, since this one might turn out to be pretty controversial, I > welcome the list to comment on this one. The order_by().get() idea > does fall in the category of "nonsensical" as opposed to "ambiguous" , > perhaps thats the distinction we'd want to go on. What other changes (that you can recall off-hand) fall into these two distinctions? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: bug? order_by + get(some_id) results in InvalidRequestError
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 ORDER BY LIMIT 2
>
> Whereas other users feel that the second query only should issue:
> SELECT * FROM (SELECT * FROM table WHERE LIMIT 2) ORDER BY
>
>
> 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 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
-~--~~~~--~~--~--~---
[sqlalchemy] Re: bug? order_by + get(some_id) results in InvalidRequestError
as usual, since this one might turn out to be pretty controversial, I welcome the list to comment on this one. The order_by().get() idea does fall in the category of "nonsensical" as opposed to "ambiguous" , perhaps thats the distinction we'd want to go on. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: bug? order_by + get(some_id) results in InvalidRequestError
On Sep 4, 2008, at 6:38 PM, Jon wrote: > I'd still like to request that order by be allowed - there is a big > difference between "makes no sense" and "is an error". At the moment I'm pretty convinced that allowing "makes no sense" to pass through silently is poor 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: bug? order_by + get(some_id) results in InvalidRequestError
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 ORDER BY LIMIT 2
Whereas other users feel that the second query only should issue:
SELECT * FROM (SELECT * FROM table WHERE LIMIT 2) ORDER BY
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
-~--~~~~--~~--~--~---
[sqlalchemy] Re: bug? order_by + get(some_id) results in InvalidRequestError
On Sep 4, 5:31 pm, Michael Bayer <[EMAIL PROTECTED]> wrote: > On Sep 4, 2008, at 5:33 PM, Jon wrote: > > > > > I'll note that if I use something like this in the ORM mapper > > definition: > > > order_by=meta.tables['some_table'].c.some_column, > > > get(pkey) continues to work *and* ORDER BY is used in the SQL. > > While ORDER BY doesn't make sense when acquiring just one item, it > > doesn't hurt either, and it's one small thing that people converting > > from 0.4 would need to know. Is there any reason why compatibility > > cannot be retained? > > get() should not be using the order_by specified in mapper(). If it > is, that's a bug. In 0.5, since the Query is becoming much more > comprehensive and richly featured than it used to be, it's important > that it does not allow operations which make no sense to proceed. It is. I'd still like to request that order by be allowed - there is a big difference between "makes no sense" and "is an error". In this case, sqlalchemy is making an error out of sometime that doesn't need to be - the SQL is perfectly valid and doesn't impact the result whatsoever, negatively or positively (in the case of get()). Ordering isn't exactly a /condition/ of the query as it is manipulation of the result - it's not filtering the results or anything of that nature. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: bug? order_by + get(some_id) results in InvalidRequestError
On Sep 4, 2008, at 5:33 PM, Jon wrote: > > I'll note that if I use something like this in the ORM mapper > definition: > > order_by=meta.tables['some_table'].c.some_column, > > get(pkey) continues to work *and* ORDER BY is used in the SQL. > While ORDER BY doesn't make sense when acquiring just one item, it > doesn't hurt either, and it's one small thing that people converting > from 0.4 would need to know. Is there any reason why compatibility > cannot be retained? get() should not be using the order_by specified in mapper(). If it is, that's a bug.In 0.5, since the Query is becoming much more comprehensive and richly featured than it used to be, it's important that it does not allow operations which make no sense to proceed. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: bug? order_by + get(some_id) results in InvalidRequestError
On Sep 4, 4:33 pm, Jon <[EMAIL PROTECTED]> wrote:
> On Sep 4, 3:32 pm, Michael Bayer <[EMAIL PROTECTED]> wrote:
>
>
>
> > On Sep 4, 2008, at 4:17 PM, Jon wrote:
>
> > > I'm using 0.4.6 but I thought I'd give 0.5b3 a try.
>
> > > An existing (working) query failed with:
>
> > > Query.__no_criterion() being called on a Query with existing
> > > criterion.
>
> > > I tracked that down to using order_by when building the query.
> > > An example is below:
>
> > > q = dbsess.query(Obj)
> > > q = q.order_by(Obj.name)
> > > instance = q.get(some_id)
>
> > > Why does this happen and is it a bug?
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).
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[sqlalchemy] Re: bug? order_by + get(some_id) results in InvalidRequestError
On Sep 4, 3:32 pm, Michael Bayer <[EMAIL PROTECTED]> wrote: > On Sep 4, 2008, at 4:17 PM, Jon wrote: > > > > > > > I'm using 0.4.6 but I thought I'd give 0.5b3 a try. > > > An existing (working) query failed with: > > > Query.__no_criterion() being called on a Query with existing > > criterion. > > > I tracked that down to using order_by when building the query. > > An example is below: > > > q = dbsess.query(Obj) > > q = q.order_by(Obj.name) > > instance = q.get(some_id) > > > Why does this happen and is it a bug? > > it doesn't make sense to call order_by() before calling get(). SQLA > raises an error instead of silently ignoring criterion which can't be > applied. I'll note that if I use something like this in the ORM mapper definition: order_by=meta.tables['some_table'].c.some_column, get(pkey) continues to work *and* ORDER BY is used in the SQL. While ORDER BY doesn't make sense when acquiring just one item, it doesn't hurt either, and it's one small thing that people converting from 0.4 would need to know. Is there any reason why compatibility cannot be retained? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: bug? order_by + get(some_id) results in InvalidRequestError
On Sep 4, 2008, at 4:32 PM, Michael Bayer wrote: > > > On Sep 4, 2008, at 4:17 PM, Jon wrote: > >> >> I'm using 0.4.6 but I thought I'd give 0.5b3 a try. >> >> An existing (working) query failed with: >> >> Query.__no_criterion() being called on a Query with existing >> criterion. >> >> I tracked that down to using order_by when building the query. >> An example is below: >> >> q = dbsess.query(Obj) >> q = q.order_by(Obj.name) >> instance = q.get(some_id) >> >> Why does this happen and is it a bug? > > it doesn't make sense to call order_by() before calling get(). SQLA > raises an error instead of silently ignoring criterion which can't be > applied. > I made a correction in r5084 such that the message is now: sqlalchemy.exc.InvalidRequestError: Query.get() being called on a Query with existing criterion. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[sqlalchemy] Re: bug? order_by + get(some_id) results in InvalidRequestError
On Sep 4, 2008, at 4:17 PM, Jon wrote: > > I'm using 0.4.6 but I thought I'd give 0.5b3 a try. > > An existing (working) query failed with: > > Query.__no_criterion() being called on a Query with existing > criterion. > > I tracked that down to using order_by when building the query. > An example is below: > > q = dbsess.query(Obj) > q = q.order_by(Obj.name) > instance = q.get(some_id) > > Why does this happen and is it a bug? it doesn't make sense to call order_by() before calling get(). SQLA raises an error instead of silently ignoring criterion which can't be applied. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
