[Hibernate-JIRA] Created: (HHH-3807) Adding a restriction to a many-to-one entity in Criteria query causes Join fetching
by Jonathan Gordon (JIRA)
Adding a restriction to a many-to-one entity in Criteria query causes Join fetching
-----------------------------------------------------------------------------------
Key: HHH-3807
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3807
Project: Hibernate Core
Issue Type: Bug
Components: query-criteria
Affects Versions: 3.3.1
Environment: Hibernate 3.3.1GA
Sql Server 2005
Reporter: Jonathan Gordon
Priority: Minor
When performing a criteria query that includes a restriction on a many-to-one entity, the associated entity is fetched eagerly, as if FetchMode were set to "JOIN". Explicitly setting the FetchMode to "SELECT" does not override this behavior.
For instance, this criteria query:
Criteria criteria = persistenceService.getCriteria(MailingParcel.class)
.createAlias("mailingCampaign", "mc")
.add(Restrictions.ge("mc.id", 1))
.setMaxResults(10);
Yields the following sql:
select
top 10 this_.ID as ID17_1_,
this_.KEYCODE as KEYCODE17_1_,
this_.CAMPAIGN_ID as CAMPAIGN3_17_1_,
this_.MAILING_LIST_MAILING_ID as MAILING4_17_1_,
this_.COUNTRY_LE_ID as COUNTRY5_17_1_,
this_.MATCH_ADDRESS as MATCH6_17_1_,
this_.ADDRESS as ADDRESS17_1_,
this_.MATCH_NAME as MATCH8_17_1_,
this_.FIRST_NAME as FIRST9_17_1_,
this_.LAST_NAME as LAST10_17_1_,
this_.ZIP_CODE asZIP11_17_1_,
this_.CITY as CITY17_1_,
this_.STATE as STATE17_1_,
this_.COMPANY as COMPANY17_1_,
mc1_.ID as ID6_0_,
mc1_.NOTE as NOTE6_0_,
mc1_.NAME as NAME6_0_,
mc1_.DATE_CREATED as DATE5_6_0_,
mc1_.DATE_MODIFIED as DATE6_6_0_,
mc1_.START_DATE as START7_6_0_,
mc1_.SOURCE_FILE_NAME as SOURCE8_6_0_,
mc1_.ORDINAL as ORDINAL6_0_,
mc1_.KEYCODE_SUFFIX as KEYCODE10_6_0_,
mc1_.MATCH_CATALOG_ID as MATCH11_6_0_,
mc1_.ADDRESS_IMPORT_DATE as ADDRESS12_6_0_
from MATCH_MAILING_CAMPAIGN this_
inner join MATCH_CAMPAIGN_INFO mc1_ on this_.CAMPAIGN_ID=mc1_.ID
where mc1_.ID>=1
However, removing the restriction yields the following sql:
select
top 10 this_.ID as ID17_0_,
this_.KEYCODE as KEYCODE17_0_,
this_.CAMPAIGN_ID as CAMPAIGN3_17_0_,
this_.MAILING_LIST_MAILING_ID as MAILING4_17_0_,
this_.COUNTRY_LE_ID as COUNTRY5_17_0_,
this_.MATCH_ADDRESS as MATCH6_17_0_,
this_.ADDRESS as ADDRESS17_0_,
this_.MATCH_NAME as MATCH8_17_0_,
this_.FIRST_NAME as FIRST9_17_0_,
this_.LAST_NAME as LAST10_17_0_,
this_.ZIP_CODE as ZIP11_17_0_,
this_.CITY as CITY17_0_,
this_.STATE as STATE17_0_,
this_.COMPANY as COMPANY17_0_
from MATCH_MAILING_CAMPAIGN this_
Performing the original query in its HQL analog does not have this problem.
--
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
15 years
[Hibernate-JIRA] Created: (HHH-2544) Create the EntityPersisters in order based on Inheritance hierarchy
by Shawn Clowater (JIRA)
Create the EntityPersisters in order based on Inheritance hierarchy
-------------------------------------------------------------------
Key: HHH-2544
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2544
Project: Hibernate3
Issue Type: New Feature
Components: core
Affects Versions: 3.2.3
Reporter: Shawn Clowater
Priority: Minor
I have a bit of what might seem to be an odd request.
I had run into a scenario where filters on my mappings that were part of a Single Table hierarchy were not getting into the configuration and it turned out it was based on the order that the EntityPersisters were being created as we've doing some minor magic with Custom EntityPersisters for filters.
In our case we have a filter template where the filter is pretty much the same for each class that implements it except for the table and key name used in the filter.
So, rather than define this annotation everywhere (we had previously been using xdoclet to generate it for the hbm mappings) we pushed the logic into a Custom Persister.
So, essentially as it is building the EntityPersister we intercept the PersistentClass before it calls the super() constructor and add our required filters on the PersistantClass (in its FilterMap) before it gets passed up. This is done like this because by the time it gets to the AbstractEntityPersister's constructor it uses the filterMap to construct the FilterHelper and then you're done as you have no access to change that after it is built.
So, in the Inheritance case any subclasses that are built before the main root class will not have the filters that we inject during the construction of our Custom Entity Persisters. I have temporarily worked around it by changing the Subclasses getFilterMap() method to not only return the filters from the Parent class but also from the class itself. Now, normally you can't define the filter on the subclass but I can through the persister.
What I'd like to do is:
Make the persister class for the subclasses a 'standard' persister that doesn't add any filters to the subclass.
Still have my root class' entity persister adding the filters.
But have the Entity Persisters built in hierarchal order in the SessionFactoryImpl.
Since they are being built in any given order right now, I can't see an issue with providing some order to them, something like the AnnotationBinder does.
--
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
15 years
[Hibernate-JIRA] Created: (HHH-3574) ANY mapping ignores lazy="false"
by Manuel Dominguez Sarmiento (JIRA)
ANY mapping ignores lazy="false"
--------------------------------
Key: HHH-3574
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3574
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.3.1
Reporter: Manuel Dominguez Sarmiento
We have a use case for eager fetching of an <any> association. The DTD accepts lazy="false|true", however at runtime it doesn't make any difference.
Digging deeper, we see that org.hibernate.mapping.Any does not have a lazy property, furthermore, it does not extend Fetchable. This explains why it will not work as expected.
There are two possible resolutions:
1) Implement eager fetching for <any> associations, unless there is some technical difficulty in doing so. Of course lazy fetching won't be possible using joins because of the nature of this type of associations, however it should be simple enough with a second select. This means that the XML config should handle lazy="false|true" but not fetch="join|select|subselect|etc"
2) Fix the DTD in case this can't be done to avoid confusion (less desirable).
--
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
15 years
[Hibernate-JIRA] Created: (HV-458) Wrong behaviour determining default group constraints in conjunction with @GroupSequence
by Hardy Ferentschik (JIRA)
Wrong behaviour determining default group constraints in conjunction with @GroupSequence
----------------------------------------------------------------------------------------
Key: HV-458
URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-458
Project: Hibernate Validator
Issue Type: Bug
Reporter: Hardy Ferentschik
See https://forum.hibernate.org/viewtopic.php?f=9&t=1010136&start=0
In a class hierarchy with more than two classes where the middle class overrides the default group sequence the wrong constraints are executed.
This can be reproduces with
{code}
public class GroupTest {
private static Validator validator;
@BeforeClass
public static void setUp() {
ValidatorFactory factory = Validation.buildDefaultValidatorFactory();
validator = factory.getValidator();
}
@Test
public void testDriveAway() {
// create a car and check that everything is ok with it.
Car car = new Car( "Morris", "DD-AB-123", 2 );
Set<ConstraintViolation<Car>> constraintViolations = validator.validate( car );
assertEquals( 0, constraintViolations.size() );
// but has it passed the vehicle inspection?
constraintViolations = validator.validate( car, CarChecks.class );
assertEquals( 1, constraintViolations.size() );
assertEquals(
"The car has to pass the vehicle inspection first", constraintViolations.iterator().next().getMessage()
);
// let's go to the vehicle inspection
car.setPassedVehicleInspection( true );
assertEquals( 0, validator.validate( car ).size() );
// now let's add a driver. He is 18, but has not passed the driving test yet
Driver john = new Driver( "John Doe" );
john.setAge( 18 );
car.setDriver( john );
constraintViolations = validator.validate( car, DriverChecks.class );
assertEquals( 1, constraintViolations.size() );
assertEquals( "You first have to pass the driving test", constraintViolations.iterator().next().getMessage() );
// ok, John passes the test
john.passedDrivingTest( true );
assertEquals( 0, validator.validate( car, DriverChecks.class ).size() );
// just checking that everything is in order now
assertEquals( 0, validator.validate( car, Default.class, CarChecks.class, DriverChecks.class ).size() );
}
@Test
public void testOrderedChecks() {
Car car = new Car( "Morris", "DD-AB-123", 2 );
car.setPassedVehicleInspection( true );
Driver john = new Driver( "John Doe" );
john.setAge( 18 );
john.passedDrivingTest( true );
car.setDriver( john );
assertEquals( 0, validator.validate( car, OrderedChecks.class ).size() );
}
@Test
public void testOrderedChecksWithRedefinedDefault() {
RentalCar rentalCar = new RentalCar( "Morris", "DD-AB-123", 2 );
rentalCar.setPassedVehicleInspection( true );
Driver john = new Driver( "John Doe" );
john.setAge( 18 );
john.passedDrivingTest( true );
rentalCar.setDriver( john );
assertEquals( 0, validator.validate( rentalCar, Default.class, DriverChecks.class ).size() );
}
@Test
public void testOrderedChecksFailsFast() {
RentalCar rentalCar = new RentalCar( "Morris", "DD-AB-123", 0 );
// This should not create a violation exception due to the 0 seat count failing first due to the GroupSequence on RentalCar
rentalCar.setPassedVehicleInspection( false );
Driver john = new Driver( "John Doe" );
john.setAge( 18 );
john.passedDrivingTest( true );
rentalCar.setDriver( john );
assertEquals( 1, validator.validate( rentalCar ).size() );
assertEquals(
validator.validate( rentalCar ).iterator().next()
.getPropertyPath().toString(), "seatCount"
);
rentalCar.setSeatCount( 4 );
assertEquals( 1, validator.validate( rentalCar ).size() );
assertEquals(
validator.validate( rentalCar ).iterator().next()
.getPropertyPath().toString(), "passedVehicleInspection"
);
}
@Test
public void testSubclassesInheritGroupSequence() {
//Our assertion here is based around Item C from Section 3.4.5 of the JSR 303 Validation Spec
//that class X (MiniRentalCar) without explicitly defining a Default group would then inherit
//it's superclasse's "Default" constraints along with it's own attribute level constraints
//not explicitly tied to a group other than Default.
class MiniRentalCar extends RentalCar {
public MiniRentalCar(String manufacturer, String licencePlate, int seatCount) {
super( manufacturer, licencePlate, seatCount );
}
}
MiniRentalCar miniRentalCar = new MiniRentalCar( "Morris", "DD-AB-123", 0 );
// This should not create a violation exception due to the 0 seat count.
miniRentalCar.setPassedVehicleInspection( false );
Driver john = new Driver( "John Doe" );
john.setAge( 18 );
john.passedDrivingTest( true );
miniRentalCar.setDriver( john );
assertEquals( 1, validator.validate( miniRentalCar ).size() );
assertEquals(
validator.validate( miniRentalCar ).iterator().next()
.getPropertyPath().toString(), "seatCount"
);
miniRentalCar.setSeatCount( 4 );
assertEquals( 1, validator.validate( miniRentalCar ).size() );
assertEquals(
validator.validate( miniRentalCar ).iterator().next()
.getPropertyPath().toString(), "passedVehicleInspection"
);
}
@Test
public void testExplicitGroupSequenceOnSubclass() {
//With the testSubclassesInheritGroupSequence test failing, we then try
//a similar test case whereby we explicitly set the Default group for this class.
@GroupSequence( { AnotherMiniRentalCar.class, CarChecks.class })
class AnotherMiniRentalCar extends RentalCar {
public AnotherMiniRentalCar(String manufacturer, String licencePlate, int seatCount) {
super( manufacturer, licencePlate, seatCount );
}
}
AnotherMiniRentalCar anotherMiniRentalCar = new AnotherMiniRentalCar( "Morris", "DD-AB-123", 0 );
// This should not create a violation exception due to the 0 seat count.
anotherMiniRentalCar.setPassedVehicleInspection( false );
Driver john = new Driver( "John Doe" );
john.setAge( 18 );
john.passedDrivingTest( true );
anotherMiniRentalCar.setDriver( john );
assertEquals( 1, validator.validate( anotherMiniRentalCar ).size() );
assertEquals(
validator.validate( anotherMiniRentalCar ).iterator().next()
.getPropertyPath().toString(), "seatCount"
);
anotherMiniRentalCar.setSeatCount( 4 );
assertEquals( 1, validator.validate( anotherMiniRentalCar ).size() );
assertEquals(
validator.validate( anotherMiniRentalCar ).iterator().next()
.getPropertyPath().toString(), "passedVehicleInspection"
);
}
}
{code}
--
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
15 years
[Hibernate-JIRA] Created: (HHH-5276) Table REVINFO created in the default schema even if the property is otherwise set
by Pascal-Eric Servais (JIRA)
Table REVINFO created in the default schema even if the property is otherwise set
---------------------------------------------------------------------------------
Key: HHH-5276
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5276
Project: Hibernate Core
Issue Type: Bug
Components: envers
Affects Versions: 3.5.2
Environment: Hibernate 3.5.2
Mysql (Ver 14.14 Distrib 5.1.37, for debian-linux-gnu (i486))
mysql-connector version 5.1.12
java version "1.6.0_0"
OpenJDK Runtime Environment (IcedTea6 1.6.1) (6b16-1.6.1-3ubuntu3)
OpenJDK Server VM (build 14.0-b16, mixed mode)
Reporter: Pascal-Eric Servais
This issue was first related here : http://community.jboss.org/message/545287 but here is a copy.
Partial configuration :
[META-INF/persistence.xml]
<persistence version="2.0"
<persistence-unit name="party" transaction-type="RESOURCE_LOCAL">
...
<properties>
<property name="hibernate.hbm2ddl.auto" value="update" />
<property name="hibernate.dialect" value="org.hibernate.dialect.MySQLDialect" />
<property name="javax.persistence.jdbc.url" value="jdbc:mysql://localhost/MODEL?useUnicode=true&characterEncoding=UTF-8" />
<property name="javax.persistence.jdbc.driver" value="com.mysql.jdbc.Driver" />
<property name="javax.persistence.jdbc.user" value="root" />
<property name="javax.persistence.jdbc.password" value="" />
...
<property name="org.hibernate.envers.default_schema" value="AUDIT"/>
...
<!-- All EventListeners Are Defined -->
</persistence-unit>
[META-INF/orm.xml]
<entity-mappings xmlns="http://java.sun.com/xml/ns/persistence/orm" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://java.sun.com/xml/ns/persistence/orm http://java.sun.com/xml/ns/persistence/orm_2_0.xsd"
version="2.0">
<access>FIELD</access>
<entity class="com.company.model.Party">
<table name="PARTY" schema="MODEL" />
...
</entity>
...
</entity-mappings>
As expected, the PARTY table is created into the MODEL schema and the audit table PARTY_AUD is created into the AUDIT schema. But the REVINFO table is created into the MODEL schema. According to the property "org.hibernate.envers.default_schema", it should be created into the AUDIT schema.
--
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
15 years