if we make this wait for 1.2 I'm hoping 1.2 is in the early spring as is
typical for the x.y releases. I'm desperately trying to trim the scope
of 1.2 (to include things like this, exclude more fundamental
"correctness" types of things) as all these x.y releases always balloon
in size and I'd like to reduce the gap between them.
in this case, we have a behavior that hasn't really changed for many
years, a fix that would change the SQL results for an application that
is using this pattern, and you also have a simple workaround.
It's not clear if applications that happen to be unknowingly doing this
are experiencing the "right" behavior, because they really wanted to
query against the base class anyway, or are experiencing the "wrong"
behavior and not realizing it. If I did put this fix out in a 1.1.x,
it's very likely I'll never hear about it, that is, probably nobody is
doing this query because they realized i doesn't work.
From my end it's less controversial to push it to 1.2 where people can
expect minor behavioral changes rather than as a point release where it
has an admittedly very low chance of breaking someone's application.
On 01/17/2017 04:19 AM, Michael Williamson wrote:
Thanks! Is there any plan for a 1.2 release in the near future?
On Mon, 16 Jan 2017 12:54:05 -0500
mike bayer <[email protected]> wrote:
issue
https://bitbucket.org/zzzeek/sqlalchemy/issues/3891/single-inh-criteria-should-be-added-for
is added. Targeted at 1.2 as it will break applications unknowingly
relying upon the bug right now.
For now say func.count(Manager.employee_id), e.g. put the entity in
the columns clause.
On 01/16/2017 12:23 PM, Michael Williamson wrote:
Hello!
I have a use case where I want to select from a polymorphic table,
but without selecting any columns from that table. As a simple
example, consider selecting the count of all rows. When I write
something like:
sess.query(func.count(1)).select_from(Manager).all()
It seems to be equivalent to:
sess.query(func.count(1)).select_from(Employee).all()
(where Manager inherits from Employee).
Is this intended, or is this a bug? If the former, what's the
suggested approach to writing such queries? To filter on the
discriminator explicitly?
For reference, I was able to reproduce the issue with a test case in
test/orm/inheritance/test_single.py:
def test_select_from_inherited_tables(self):
Manager, Engineer, Employee = (self.classes.Manager,
self.classes.Engineer, self.classes.Employee)
sess = create_session()
m1 = Manager(name='Tom', manager_data='data1')
e1 = Engineer(name='Kurt', engineer_info='knows how to
hack') sess.add_all([m1, e1])
sess.flush()
eq_(
sess.query(func.count(1)).select_from(Manager).all(),
[(1, )]
)
Thanks
Michael
--
SQLAlchemy -
The Python SQL Toolkit and Object Relational Mapper
http://www.sqlalchemy.org/
To post example code, please provide an MCVE: Minimal, Complete, and Verifiable
Example. See http://stackoverflow.com/help/mcve for a full description.
---
You received this message because you are subscribed to the Google Groups "sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at https://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.
