Thanks for all the feedback! I think I'm OK on the process part of submitting a patch, (e.g. I have a pull request for a different issue in the submission queue).
On the technical merits, I think I should be able to provide a convincing test that the current behavior isn't compatible with the spec. E.g. in the example from the Jira issue, if a BPrime row wasn't in the database, its corresponding B shouldn't come back in that query, either. I'm not sure I understood Gunnar's point: >However, if the use of derived tables is restricted to related entities, it will comply with the docs and still behave more properly. What do you mean by related entities here? I'm thinking the spec really wants the inner join: If set to join, the default, Hibernate will use an inner join to retrieve a <join> defined by a class or its superclasses and an outer join for a <join> defined by a subclass. Certainly, I need to only use a derived table when BPrime is defined on B and not one of B's subclasses. Also, only when optional=false. But am I missing something more? Thanks, Isaac On Tue, Oct 4, 2011 at 5:36 AM, Richard Brown (gmail) < [email protected]> wrote: > > > 3. Any pointers one where I should start? I know my way around the code > base a little bit, but if anyone has some advice on how to attack this > issue, I'd appreciate it. > > Start with a failing test ... that alone could be pulled/cherry-picked into > the master branch (and flagged as [Ignore] until it is implemented.) > > >
