[Hibernate-JIRA] Commented: (HHH-1015) Incorrect SQL generated when one-to-many foreign key is in a discriminated subclass table
by Krasimir Chobantonov (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1015?page=c... ]
Krasimir Chobantonov commented on HHH-1015:
-------------------------------------------
I spoke too early - it seems that the code that I provided fixes only the issue with duplicate column creation (payer_id).
I will investigate why the hibernate is using creation the wrong SQL - e.g. using the payer_id with the wrong table...
> Incorrect SQL generated when one-to-many foreign key is in a discriminated subclass table
> -----------------------------------------------------------------------------------------
>
> Key: HHH-1015
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1015
> Project: Hibernate Core
> Issue Type: Bug
> Components: core
> Affects Versions: 3.1 beta 2
> Environment: Hibernate versions 3.1 beta 3 and 3.0.5
> Reporter: Steven Grimm
> Priority: Minor
>
> I have the following mappings describing a hierarchy of events and a class that the events refer to:
> <hibernate-mapping package="com.xyz">
> <class name="Event" table="event" discriminator-value="-1">
> <id name="Id" type="long" column="event_id"/>
> <discriminator column="event_type_id" type="integer" />
> <subclass name="EventPayer" discriminator-value="-3">
> <join table="event_payer">
> <key column="event_id" />
> <many-to-one name="payer" column="payer_id" class="Payer" />
> </join>
> <subclass name="EventPayerCreated" discriminator-value="1" />
> </subclass>
> </class>
> <class name="Payer" table="payer">
> <id name="payerId" column="payer_id" type="java.lang.Long"/>
> <set name="eventPayers" inverse="true" cascade="save-update">
> <key column="payer_id"/>
> <one-to-many class="EventPayer"/>
> </set>
> </class>
> </hibernate-mapping>
> When I fetch the Payer.eventPayers collection, Hibernate generates this SQL:
> select eventpayer0_.payer_id as payer7_1_,
> eventpayer0_.event_id as event1_1_,
> eventpayer0_.event_id as event1_5_0_,
> eventpayer0_1_.payer_id as payer2_6_0_,
> eventpayer0_.event_type_id as event2_5_0_
> from event eventpayer0_
> inner join event_payer eventpayer0_1_
> on eventpayer0_.event_id=eventpayer0_1_.event_id
> where eventpayer0_.payer_id=?
> The problem is that there is no event.payer_id column; payer_id is in the child table, not the parent. It appears that specifying a discriminated subclass in <one-to-many> is the same as specifying the superclass, or that Hibernate is ignoring the subclass's <join> element. As far as I can tell, this leaves no way to resolve bidirectional associations where one end of the association is in a discriminated subclass, which seems like a perfectly reasonable thing to want to do.
> I also tried changing <key column="payer_id"/> to <key property-ref="payer"/> in the Payer class's <set> element, but got similar behavior in the form of a "property not found" error: Hibernate is either looking in the superclass's properties rather than the subclass's or is ignoring the list of properties in the <join> element.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 4 months
[Hibernate-JIRA] Commented: (HHH-1015) Incorrect SQL generated when one-to-many foreign key is in a discriminated subclass table
by Krasimir Chobantonov (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1015?page=c... ]
Krasimir Chobantonov commented on HHH-1015:
-------------------------------------------
The problem seems to be in the HbmBinder on line 2380 where the following code exist
collection.setCollectionTable( persistentClass.getTable() );
if the line is changed to the following code snippet then the problem seems to disappear.
if ( collection.getCollectionTable() == null ) {
collection.setCollectionTable( persistentClass.getTable() );
}
> Incorrect SQL generated when one-to-many foreign key is in a discriminated subclass table
> -----------------------------------------------------------------------------------------
>
> Key: HHH-1015
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1015
> Project: Hibernate Core
> Issue Type: Bug
> Components: core
> Affects Versions: 3.1 beta 2
> Environment: Hibernate versions 3.1 beta 3 and 3.0.5
> Reporter: Steven Grimm
> Priority: Minor
>
> I have the following mappings describing a hierarchy of events and a class that the events refer to:
> <hibernate-mapping package="com.xyz">
> <class name="Event" table="event" discriminator-value="-1">
> <id name="Id" type="long" column="event_id"/>
> <discriminator column="event_type_id" type="integer" />
> <subclass name="EventPayer" discriminator-value="-3">
> <join table="event_payer">
> <key column="event_id" />
> <many-to-one name="payer" column="payer_id" class="Payer" />
> </join>
> <subclass name="EventPayerCreated" discriminator-value="1" />
> </subclass>
> </class>
> <class name="Payer" table="payer">
> <id name="payerId" column="payer_id" type="java.lang.Long"/>
> <set name="eventPayers" inverse="true" cascade="save-update">
> <key column="payer_id"/>
> <one-to-many class="EventPayer"/>
> </set>
> </class>
> </hibernate-mapping>
> When I fetch the Payer.eventPayers collection, Hibernate generates this SQL:
> select eventpayer0_.payer_id as payer7_1_,
> eventpayer0_.event_id as event1_1_,
> eventpayer0_.event_id as event1_5_0_,
> eventpayer0_1_.payer_id as payer2_6_0_,
> eventpayer0_.event_type_id as event2_5_0_
> from event eventpayer0_
> inner join event_payer eventpayer0_1_
> on eventpayer0_.event_id=eventpayer0_1_.event_id
> where eventpayer0_.payer_id=?
> The problem is that there is no event.payer_id column; payer_id is in the child table, not the parent. It appears that specifying a discriminated subclass in <one-to-many> is the same as specifying the superclass, or that Hibernate is ignoring the subclass's <join> element. As far as I can tell, this leaves no way to resolve bidirectional associations where one end of the association is in a discriminated subclass, which seems like a perfectly reasonable thing to want to do.
> I also tried changing <key column="payer_id"/> to <key property-ref="payer"/> in the Payer class's <set> element, but got similar behavior in the form of a "property not found" error: Hibernate is either looking in the superclass's properties rather than the subclass's or is ignoring the list of properties in the <join> element.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 4 months
[Hibernate-JIRA] Commented: (HHH-530) Allow application of filters on subqueries
by Shawn Clowater (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-530?page=co... ]
Shawn Clowater commented on HHH-530:
------------------------------------
Steve, the above patch fixes an issue I had with my orginal. I'm not extremely happy with the instanceof check but it was the only way that I could handle the 2 cases w/o making some broader API changes). It addresses the fact that as you get deeper and deeper into a subquery stack you don't have the session readily available to get the enabled filters off of.
I've also expanded the DynamicFilterTest suite to include a few more Criteria examples and added the HQL ones as I've been banging my head against the wall seeing if there was a silver bullet short term solution to having it all play nicely.
On the Criteria side of things I believe it all hangs together it is the HQL side that was the rat's nest for me. Mere mortals shouldn't be bombing around inside the AST parser. I will say that the move the maven and the pom files are a godsend. It is some nice to be able to have the project quickly up in Idea in order to do things like debug single unit tests, etc.
I think you're right in it would be nice to have the parameters in the HQL AST tree. Some of my observations with the problems in HQL that you probably already sorted out for yourself are:
-if there are 0 named parameters then simply commenting out the overloaded bindParameterValues in QueryLoader allows the filters to be applied to the HQL (with the addition of commenting out the piece in JoinProcessor
-again the issue with the named parameters is that by the time the parsing is done they have essentially been replaced by positional parameters. I tried to get those values back into a preprocessedPositionalParameters array or something that the processFilters piece could use but during the parsing phase there didn't seem to be any access to the QueryParameters in order to do that. (which makes sense now once I realized that the parse in done when generating the HQL plan). ****Will this mesh with your idea of having the values in the HQL AST tree and pulling their values since the plan can be cached. I would think you'd need to throw out the plan if any filters are enabled as the resulting HQL could be different in each case?
-assuming that you can get the filters into the tree before the parsing, I think it is a simple case or just finding the ":" like it is now and then checking to see if the named param after that matches a filter, if it does then build a DynamicFilterParameterSpecification, otherwise it is a simple NamedParameterSpecification.
-If the DynamicFilterParameterSpecification can be properly built then you wouldn't need to call the processFilters piece as everything would have been parsed in the correct order so you would want to skip parsing the complete query a second time from the loader.
> Allow application of filters on subqueries
> ------------------------------------------
>
> Key: HHH-530
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-530
> Project: Hibernate Core
> Issue Type: Patch
> Components: core
> Reporter: Gavin King
> Assignee: Steve Ebersole
> Fix For: 3.3.x
>
> Attachments: HHH-530.3.3.SP1.patch, HHH-530.3.3.SP1.take2.patch, HHH-530.Additional.Subquery.patch, HHH-530.patch, hibernate_filter_fix-3.0.5.patch, hibernate_filter_fix-3.0.5_14.patch, SubqueriesWithFiltersTest.patch
>
>
> Currently filter conditions are applied in subselects, they should not be.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 4 months
[Hibernate-JIRA] Commented: (HHH-530) Allow application of filters on subqueries
by Steve Ebersole (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-530?page=co... ]
Steve Ebersole commented on HHH-530:
------------------------------------
I am looking at it as well. For this and for other reasons as well, I think a much better solution is to simply embed the parameters into the HQL AST tree and have them "pull" their values from QueryParameters (currently the values are "pushed" from QueryParameters by Loader). This has benefits in many use-cases.
There is a trade-off in this approach in that after parsing and translation we must collect the query parameters (the ParameterSpecifications) in order to iterate them for binding. Not sure yet of the performance impact of that change. Another option that would perform much better would be to collect the ParameterSpecifications during sql.g processing. This later option is what I intend for later. Just not sure how feasible it is given the mix of AST and JoinFragment/JoinSequences currently in the HQL translator.
> Allow application of filters on subqueries
> ------------------------------------------
>
> Key: HHH-530
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-530
> Project: Hibernate Core
> Issue Type: Patch
> Components: core
> Reporter: Gavin King
> Assignee: Steve Ebersole
> Fix For: 3.3.x
>
> Attachments: HHH-530.3.3.SP1.patch, HHH-530.Additional.Subquery.patch, HHH-530.patch, hibernate_filter_fix-3.0.5.patch, hibernate_filter_fix-3.0.5_14.patch, SubqueriesWithFiltersTest.patch
>
>
> Currently filter conditions are applied in subselects, they should not be.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 4 months
[Hibernate-JIRA] Commented: (HHH-530) Allow application of filters on subqueries
by Shawn Clowater (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-530?page=co... ]
Shawn Clowater commented on HHH-530:
------------------------------------
Steve, your timing is impeccable as I went back to the well and started playing with this quite a bit.
I expanded the DynamicFilterTest to include the same queries I did on the Criteria side and mimiced them in HQL to initially verify that they failed due to the filter not being applied at all. I then commented out that line of code in the JoinProcessor and some of them started to work. It wasn't apparent at first but in some cases the values were being bound in the incorrect order and for the longest time I couldn't figure why.
I then noticed the bindParameterValues was being overridden and that is where the new problem lies. It is making the same assumption that the QueryParameters used to, that being that all of the filter parameters are at the start of the query as it tries to process the filters first and then apply the remaining parameters as it was processed from the ASTParser.
At first I just commented that out and it worked fine for the tests that I wrote but then broke some of the tests in ASTParsingLoaderTest (it's never easy). I've got it somewhat working right now (very dirty) but I am going to write a few more tests and then see if it still holds. I want to try a mix/match of named/positional with hql and filters enabled and see what happens (I think it'll fail with what I currently have)
I'll post everything up once I'm done, I did find a bit of a bug in my Criteria side of the handling, i.e. I can still hit a class cast when trying to cast the Criteria to a CriteriaImpl in the case of a nested subquery but I think I have a fix for that as well. Looking back through the comments it would appear that I thought I had that fixed at some point but I either uploaded the wrong patch and/or interpreted my results correctly as it didn't work.
> Allow application of filters on subqueries
> ------------------------------------------
>
> Key: HHH-530
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-530
> Project: Hibernate Core
> Issue Type: Patch
> Components: core
> Reporter: Gavin King
> Assignee: Steve Ebersole
> Fix For: 3.3.x
>
> Attachments: HHH-530.3.3.SP1.patch, HHH-530.Additional.Subquery.patch, HHH-530.patch, hibernate_filter_fix-3.0.5.patch, hibernate_filter_fix-3.0.5_14.patch, SubqueriesWithFiltersTest.patch
>
>
> Currently filter conditions are applied in subselects, they should not be.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 4 months
[Hibernate-JIRA] Commented: (HHH-1852) @MappedSuperclass - PropertyAccessException
by Shawn Kerstetter (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1852?page=c... ]
Shawn Kerstetter commented on HHH-1852:
---------------------------------------
I want to chime in here and say that I had a very similar issue. It was reported in exactly the same way, however, my problem turned out to be in my code. I had a type mismatch in my HQL:
" and currentStatus in (:selectedStatusPrimaryKeys)"
Which I had to change to
"and currentStatus.primaryKey in (:selectedStatusPrimaryKeys)".
I am not sure why the issue manifested itself the way it did, but I am hoping that this note can save someone else the trouble that I had.
> @MappedSuperclass - PropertyAccessException
> -------------------------------------------
>
> Key: HHH-1852
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1852
> Project: Hibernate Core
> Issue Type: Bug
> Components: core
> Affects Versions: 3.2.0.cr2
> Environment: hibernate-3.2.0.cr2, hibernate-annotations-3.2.0.cr1, hibernate-entitymanager-3.2.0.cr1
> Reporter: David de Mingo
> Attachments: src.zip
>
>
> Caused by: org.hibernate.PropertyAccessException: could not get a field value by reflection getter of org.endea.model.product.ProductAttribute.data
> at org.hibernate.property.DirectPropertyAccessor$DirectGetter.get(DirectPropertyAccessor.java:35)
> at org.hibernate.property.DirectPropertyAccessor$DirectGetter.getForInsert(DirectPropertyAccessor.java:40)
> at org.hibernate.tuple.AbstractEntityTuplizer.getPropertyValuesToInsert(AbstractEntityTuplizer.java:264)
> ...
> Caused by: java.lang.IllegalArgumentException
> at sun.reflect.UnsafeFieldAccessorImpl.ensureObj(UnsafeFieldAccessorImpl.java:37)
> at sun.reflect.UnsafeObjectFieldAccessorImpl.get(UnsafeObjectFieldAccessorImpl.java:18)
> at java.lang.reflect.Field.get(Field.java:357)
> at org.hibernate.property.DirectPropertyAccessor$DirectGetter.get(DirectPropertyAccessor.java:32)
> ... 41 morer
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 4 months
[Hibernate-JIRA] Commented: (HHH-530) Allow application of filters on subqueries
by Steve Ebersole (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-530?page=co... ]
Steve Ebersole commented on HHH-530:
------------------------------------
Criteria is inherently different than HQL ;)
And they are very different in precisely the respect causing issues here : parameters.
I wrote a new Criteria query to demonstrate:
Session session = openSession();
session.beginTransaction();
session.enableFilter( "fulfilledOrders" ).setParameter( "asOfDate", testData.lastMonth.getTime() );
session.enableFilter( "regionlist" ).setParameterList( "regions", new String[] { "APAC" } );
DetachedCriteria subquery = DetachedCriteria.forClass( Salesperson.class )
.setProjection( Property.forName( "name" ) );
List result = session.createCriteria( Order.class )
.add( Subqueries.in( "steve", subquery ) )
.list();
assertEquals( 1, result.size() );
which works. And then converted it to HQL:
final String queryString = "from Order o where :salesPersonName in ( select sp.name from Salesperson sp )";
session.enableFilter( "fulfilledOrders" ).setParameter( "asOfDate", testData.lastMonth.getTime() );
session.enableFilter( "regionlist" ).setParameterList( "regions", new String[] { "APAC" } );
result = session.createQuery( queryString ).setString( "salesPersonName", "steve" ).list();
assertEquals( 1, result.size() );
which fails; or:
final String queryString = "from Order o where ? in ( select sp.name from Salesperson sp )";
session.enableFilter( "fulfilledOrders" ).setParameter( "asOfDate", testData.lastMonth.getTime() );
session.enableFilter( "regionlist" ).setParameterList( "regions", new String[] { "APAC" } );
result = session.createQuery( queryString ).setString( 0, "steve" ).list();
assertEquals( 1, result.size() );
which also fails.
> Allow application of filters on subqueries
> ------------------------------------------
>
> Key: HHH-530
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-530
> Project: Hibernate Core
> Issue Type: Patch
> Components: core
> Reporter: Gavin King
> Assignee: Steve Ebersole
> Fix For: 3.3.x
>
> Attachments: HHH-530.3.3.SP1.patch, HHH-530.Additional.Subquery.patch, HHH-530.patch, hibernate_filter_fix-3.0.5.patch, hibernate_filter_fix-3.0.5_14.patch, SubqueriesWithFiltersTest.patch
>
>
> Currently filter conditions are applied in subselects, they should not be.
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://opensource.atlassian.com/projects/hibernate/secure/Administrators....
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
16 years, 4 months