Makes sense, thanks! As you say, there is a workaround that we can use -- the only downside is having to be slightly careful when writing queries. So nice to have, but not desperate by any means.
Thanks again On Tue, 17 Jan 2017 10:13:41 -0500 mike bayer <[email protected]> wrote: > 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.
