HHH-18610 "SQLGrammarException: Unable to find column position by name" when using Single Table Inheritance with a strict JDBC driver such as PostgreSQL #9217
Conversation
hibernate-core/src/main/java/org/hibernate/query/results/dynamic/DynamicFetchBuilderLegacy.java
Show resolved
Hide resolved
| * Locate an explicit fetch definition for the named fetchable | ||
| */ | ||
| FetchBuilder findFetchBuilder(String fetchableName); | ||
| FetchBuilder findFetchBuilder(Fetchable fetchable); |
There was a problem hiding this comment.
Not sure if we consider this to be "API", but wanted to mention the backwards compatibility concern.
There was a problem hiding this comment.
It seems like all these methods here are in fact user-facing, so maybe we should keep the string variants?
There was a problem hiding this comment.
I think it's incredibly unlikely that any user code depends on DynamicFetchBuilderContainer since there are no SPIs which return or accept this type.
And therefore I don't think there's any need to worry about breaking it in a new major version.
There was a problem hiding this comment.
There was a problem hiding this comment.
The work I've done @ #9257 addresses this specific concern.
However, a natural continuation there is that everything else in the org.hibernate.query.results package should really be an spi. I started down this path, but it affects a few things that are in the same boat imo. E.g. this has ties with the org.hibernate.query.namedpackage, which itself ought to be spi imo. I'm going to follow up with a separate pr that follows that rabbit hole so we can see the full impact.
@DavideD wrt ^^, as far as I could see this change would have a minimal impact on HR so wanted to get your take. HR has an implementation of the main contract there, but like I said I think the impact for HR is minimal.
There was a problem hiding this comment.
However, a natural continuation there is that everything else in the org.hibernate.query.results package should really be an spi
Well, unless we forsee actually adding some form of support for an application creating these directly. A sort of improved approach to NativeQuery#addReturn, etc. That was the original plan, but we've not done it and no one has asked for it so...
There was a problem hiding this comment.
@DavideD wrt ^^, as far as I could see this change would have a minimal impact on HR so wanted to get your take. HR has an implementation of the main contract there, but like I said I think the impact for HR is minimal.
Yes, the impact should be minimal.
There was a problem hiding this comment.
I can try tomorrow to update the code in Hibernate Reactive and make sure that there are not surprises.
hibernate-core/src/main/java/org/hibernate/sql/ast/spi/SqlExpressionResolver.java
Outdated
Show resolved
Hide resolved
…: TYPE when using Single Table Inheritance with a strict JDBC driver such as PostgreSQL
|
close if favour of #9291 |
5 participants
https://hibernate.atlassian.net/browse/HHH-18610
the main change is to use
Fetchableinstead of the simple attribute name as key forFetchBuilders, this should fix the problem with subclasses having properties with the same name but different columns.By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license
and can be relicensed under the terms of the LGPL v2.1 license in the future at the maintainers' discretion.
For more information on licensing, please check here.