[Hibernate-JIRA] Created: (HHH-2223) BatchFetchQueue.getXXXBatch() cache check impeding batch fetching
by Joel Caplin (JIRA)
BatchFetchQueue.getXXXBatch() cache check impeding batch fetching
-----------------------------------------------------------------
Key: HHH-2223
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2223
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.0.ga
Environment: 3.2.0GA, Mac OS X/Solaris 10, Sybase 12.5/HSQLDB
Reporter: Joel Caplin
Priority: Minor
Attachments: testcase.tar
I have attached a test case which demonstrates the issue at hand by implementing a cheap data model: Pub >---|- Manager -|--< Employee
Pub and Employee are uncached; Manager is cached (tried under both Eh and the non-prod HashMap implementation). All associations are lazy. The test case has a default batch size of 10 and uses hsqldb to demonstrate the problem - which was diagnosed against Sybase.
When BatchFetchQueue.getXXXBatch() is invoked, it does not load any objects it finds in the second level cache - it merely acknowledges their presence by logging to INFO (isCached()). This in turn means that any child associations in that cached object will not have a proxy created for them.
Suppose we want to find all the employees of the pubs in our database. We choose to do this by loading all the Pubs ("FROM Pub") and calling thePub.getManager().getEmployees() iteratively.
When the managers are in the second level cache, Hibernate issues 11 select statements: one to load the pubs and one for each distinct manager.
When the Managers are not in the cache, Hibernate issues 3 select statements: one to load the pubs, one to load the managers and one to load the employees.
A solution might be to load the object from the cache instead of just ignoring it?
--
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
11 years, 6 months
[Hibernate-JIRA] Created: (HHH-2280) Not-Null Constraint-Violation with unidirectional one-to-many mapping
by Robert Herschke (JIRA)
Not-Null Constraint-Violation with unidirectional one-to-many mapping
---------------------------------------------------------------------
Key: HHH-2280
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2280
Project: Hibernate3
Type: Bug
Versions: 3.2.0.cr4
Environment: Hibernate 3.2.0.cr4, Oracle 10XE
Reporter: Robert Herschke
Priority: Blocker
Attachments: one-to-many-test.zip
In some cases it is neccessary to have an unidirectional one-to-many mapping, but not using Join-Tables due to a legacy database system.
So it must be possible, to have a one-to-many mapping just via a foreign-key-mapping. The Child-Object must not know the Parent-Object in this case.
It must also be possible, to pay respect to a NOT-NULL-Constraint at this foreign-key due to restrictions on legacy database systems.
Hibernate doesn't support this, but throw a NOT-NULL-Constraint Violation Exception. The documentation says, "this is unusual" - to which I want to dissent.
See the attached testcase for details, that is adopted from your "one-to-many" testcase found in the 3.2.0 sources.
--
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
11 years, 6 months
[Hibernate-JIRA] Created: (HHH-2165) Change logging level in TableMetadata from INFO to DEBUG or TRACE
by Igor A Tarasov (JIRA)
Change logging level in TableMetadata from INFO to DEBUG or TRACE
-----------------------------------------------------------------
Key: HHH-2165
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2165
Project: Hibernate3
Type: Improvement
Components: metamodel
Versions: 3.2.0.ga
Reporter: Igor A Tarasov
TableMetadata produce too many output to INFO log level. It good thing if it output be at DEBUG level to not hide other impotant information as service start/stop and other.
20.10.06 18:01:58 INFO [main]: SchemaUpdate - updating schema
20.10.06 18:01:58 INFO [main]: TableMetadata - table found: isp.ChageDO
20.10.06 18:01:58 INFO [main]: TableMetadata - columns: [id, _version, chagedate, created, service, sum, restbalance, comment, customer_id]
20.10.06 18:01:58 INFO [main]: TableMetadata - foreign keys: []
20.10.06 18:01:58 INFO [main]: TableMetadata - indexes: [id, fk8f40c06527214c11, chagedate, primary]
20.10.06 18:01:58 INFO [main]: TableMetadata - table found: isp.CustomerDO
20.10.06 18:01:58 INFO [main]: TableMetadata - columns: [phone, firm, group_id, deleted, fio, id, balance, created, updated, address, email, name, comment]
20.10.06 18:01:58 INFO [main]: TableMetadata - foreign keys: []
20.10.06 18:01:58 INFO [main]: TableMetadata - indexes: [id, primary, fk1892e50924b4a799, deleted]
20.10.06 18:01:58 INFO [main]: TableMetadata - table found: isp.GroupDO
20.10.06 18:01:58 INFO [main]: TableMetadata - columns: [id, updated, created, name, comment, deleted]
20.10.06 18:01:58 INFO [main]: TableMetadata - foreign keys: []
20.10.06 18:01:58 INFO [main]: TableMetadata - indexes: [id, primary, deleted]
20.10.06 18:01:58 INFO [main]: TableMetadata - table found: isp.HostDO
20.10.06 18:01:58 INFO [main]: TableMetadata - columns: [tarif_id, server_id, ips, mac, deleted, id, created, updated, name, lastactive, comment, disabled, customer_id]
20.10.06 18:01:58 INFO [main]: TableMetadata - foreign keys: []
20.10.06 18:01:58 INFO [main]: TableMetadata - indexes: [ips, name, primary, fk812f2053f280a3b1, mac, deleted, fk812f205327214c11, fk812f20537f1e2ff9]
20.10.06 18:01:58 INFO [main]: TableMetadata - table found: isp.HostSessionDO
20.10.06 18:01:58 INFO [main]: TableMetadata - columns: [id, host_id, starttime, chage, speedou, updatetime, speedin, bytesin, stoptime, bytesou, version]
20.10.06 18:01:58 INFO [main]: TableMetadata - foreign keys: []
20.10.06 18:01:58 INFO [main]: TableMetadata - indexes: [fk9a9074b995d39b51, id, primary]
20.10.06 18:01:58 INFO [main]: TableMetadata - table found: isp.LoginDO
20.10.06 18:01:58 INFO [main]: TableMetadata - columns: [id, nickname, updated, created, name, comment, password, deleted, customer_id, disabled]
20.10.06 18:01:58 INFO [main]: TableMetadata - foreign keys: []
20.10.06 18:01:58 INFO [main]: TableMetadata - indexes: [id, name, primary, fk77a0599427214c11, deleted]
20.10.06 18:01:58 INFO [main]: TableMetadata - table found: isp.PPPAccountDO
20.10.06 18:01:58 INFO [main]: TableMetadata - columns: [tarif_id, login_id, id, server_id, updated, created, comment, deleted, disabled, ip]
20.10.06 18:01:58 INFO [main]: TableMetadata - foreign keys: []
20.10.06 18:01:58 INFO [main]: TableMetadata - indexes: [id, fk507abf087f1e2ff9, primary, fk507abf08f280a3b1, fk507abf08820174d9, deleted]
20.10.06 18:01:58 INFO [main]: TableMetadata - table found: isp.PPPSessionDO
20.10.06 18:01:58 INFO [main]: TableMetadata - columns: [callerid, starttime, account_id, updatetime, speedou, chage, speedin, stoptime, bytesou, version, ip, id, ident, bytesin]
20.10.06 18:01:58 INFO [main]: TableMetadata - foreign keys: []
20.10.06 18:01:58 INFO [main]: TableMetadata - indexes: [id, fke19b413144f3fa61, starttime, ident, updatetime, primary, stoptime]
20.10.06 18:01:58 INFO [main]: TableMetadata - table found: isp.PaymentDO
20.10.06 18:01:58 INFO [main]: TableMetadata - columns: [id, _version, created, nalichka, sum, paydate, comment, newbalance, customer_id]
20.10.06 18:01:58 INFO [main]: TableMetadata - foreign keys: []
20.10.06 18:01:58 INFO [main]: TableMetadata - indexes: [id, fk7249f0f127214c11, primary, paydate]
20.10.06 18:01:58 INFO [main]: TableMetadata - table found: isp.ServerDO
20.10.06 18:01:58 INFO [main]: TableMetadata - columns: [id, updated, created, name, comment, deleted, ip]
20.10.06 18:01:58 INFO [main]: TableMetadata - foreign keys: []
20.10.06 18:01:58 INFO [main]: TableMetadata - indexes: [id, name, primary, deleted, ip]
20.10.06 18:01:58 INFO [main]: TableMetadata - table found: isp.TarifDO
20.10.06 18:01:58 INFO [main]: TableMetadata - columns: [costsizein, resetprepaidsize, prepaidsizerest, moncost, resetprepaidusages, costusage, resetprepaidtime, deleted, prepaidtimemonthly, costtime, prepaidsizemonthly, id, prepaidusagesrest, monthenddate, costsizeou, created, updated, name, prepaidtimerest, prepaidusagesmonthly, comment, customer_id]
20.10.06 18:01:58 INFO [main]: TableMetadata - foreign keys: []
20.10.06 18:01:58 INFO [main]: TableMetadata - indexes: [id, primary, fk7893f6d27214c11, deleted]
20.10.06 18:01:58 INFO [main]: SchemaUpdate - schema update complete
--
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
11 years, 7 months
[Hibernate-JIRA] Created: (HHH-2318) Sometimes wrong classloader used for proxy interfaces
by Jan Wiemer (JIRA)
Sometimes wrong classloader used for proxy interfaces
-----------------------------------------------------
Key: HHH-2318
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2318
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.1
Reporter: Jan Wiemer
For some of our business classes we used a Mapping declaring the class to be lazy initialized and providing a proxy interface like e.g.:
<class name="TestClassImpl" proxy="TestClass" table="testTable" lazy="true"> ... </class>
Using classes mapped this way - e.g. as endpoint of a one to one relation - sporadically leads to exceptions like the following:
org.hibernate.PropertyAccessException: IllegalArgumentException occurred while calling setter of test.AbstractTestClass2Impl.testField
at org.hibernate.property.BasicPropertyAccessor$BasicSetter.set(BasicPropertyAccessor.java:104)
at org.hibernate.tuple.entity.AbstractEntityTuplizer.setPropertyValues(AbstractEntityTuplizer.java:337)
at org.hibernate.tuple.entity.PojoEntityTuplizer.setPropertyValues(PojoEntityTuplizer.java:200)
at org.hibernate.persister.entity.AbstractEntityPersister.setPropertyValues(AbstractEntityPersister.java:3514)
at org.hibernate.engine.TwoPhaseLoad.initializeEntity(TwoPhaseLoad.java:129)
at org.hibernate.loader.Loader.initializeEntitiesAndCollections(Loader.java:842)
at org.hibernate.loader.Loader.doQuery(Loader.java:717)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:224)
at org.hibernate.loader.Loader.doList(Loader.java:2211)
at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2095)
at org.hibernate.loader.Loader.list(Loader.java:2090)
at org.hibernate.loader.hql.QueryLoader.list(QueryLoader.java:388)
at org.hibernate.hql.ast.QueryTranslatorImpl.list(QueryTranslatorImpl.java:338)
at org.hibernate.engine.query.HQLQueryPlan.performList(HQLQueryPlan.java:172)
at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1121)
at org.hibernate.impl.QueryImpl.list(QueryImpl.java:79)
at org.hibernate.impl.AbstractQueryImpl.uniqueResult(AbstractQueryImpl.java:804)
Note that the application is residing in a different classloader than hibernate (and CGLIB...).
Examining the situation we see that the value passed to the setter was a CGLIB proxy. Internally the proxy stores an array of interfaces the proxy should implement. In our situation this interface contains the HibernateProxy interface and our business interface provided as proxy interface in the mapping. In this interface array we checked the classloader of the interfaces. As expected the HibernateProxy interface is loaded by the system classloader and our interface was loaded by our custom classloader. However examining the actual interfaces of the proxy (with proxy.getClass().getInterfaces()[i].getClassLoader() for all i) shows that all interfaces are loaded with the system classloader. This causes the exception above.
Doing some more experiments we experience that the problem does not occur all the time. Sometimes the actual proxy interfaces are as expected (the HibernateProxy interface is loaded by the system classloader and our interface was loaded by our custom classloader). We notice that each time the test failed the HibernateProxy was the first interface in the interface array stored in the proxy.
Some experiments with the CGLIB (the Enhancer class) shows us that (if there is no superclass given) they use the classloader of the first passed interface as default classloader (compare method net.sf.cglib.proxy.Enhancer.getDefaultClassLoader()).
Finally we find out that hibernate passes the proxy interfaces in an arbitrary order since they are using a HashSet for the proxy interfaces in the method org.hibernate.tuple.entity.PojoEntityTuplizer.buildProxyFactory(PersistentClass persistentClass, Getter idGetter, Setter idSetter). This Hash set is passed to the method org.hibernate.proxy.pojo.cglib.CGLIB_ProxyFactory.postInstantiate(...). There it is simply converted to an Array (leading to a randomized order).
As a workaround it is possible to patch the class org.hibernate.proxy.pojo.cglib.CGLIB_ProxyFactory and add reorganize the array if the HibernateProxy interface is the first one:
this.interfaces = (Class[]) interfaces.toArray(NO_CLASSES);
//----->PATCH<--------
if(this.interfaces.length > 1) {
Class firstIfc = this.interfaces[0];
if(firstIfc.getName().startsWith("org.hibernate")) {
this.interfaces[0] = this.interfaces[1];
this.interfaces[1] = firstIfc;
System.err.println("Replace: " + firstIfc.getName() + " by " + this.interfaces[0].getName());
}
}
//--------------------
After applying this patch everything woks as expected.
Compare with the discussion in:
http://forum.hibernate.org/viewtopic.php?p=2334617#2334617
--
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
11 years, 8 months
[Hibernate-JIRA] Created: (HHH-2158) incorrect hql query on one-to-one with property-ref
by Sebastien Cesbron (JIRA)
incorrect hql query on one-to-one with property-ref
----------------------------------------------------
Key: HHH-2158
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2158
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.0.ga
Environment: hibernate 3.2.0.ga with firebird 1.5.3 and jaybird 1.5.5 driver on windows XP
Reporter: Sebastien Cesbron
Attachments: testhib.zip
I have a one-to-one relationship with property-ref between Master and Slave2.
I want to find all Master instances that have a null Slave2 instance associated.
To do so my query is
select master from Master master where master.slave2 is null
The sql generated is
select master0_.oid as oid0_, master0_.libelle as libelle0_ from Master master0_ where master0_.oid is null
which seems incorrect. It checks here Master instances with null id (config files are listed below).
If I do my query like this
select master from Master master where master.slave2.oid is null
the generated sql is ok :
select master0_.oid as oid0_, master0_.libelle as libelle0_ from Master master0_, Slave2 slave2x1_ where master0_.oid=slave2x1_.myMaster and (slave2x1_.oid is null)
I have attached a small eclipse project that reproduces the problem
This problem may-be related to the one I have submitted as issue HHH-1849
--
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
11 years, 9 months
[Hibernate-JIRA] Created: (HHH-2085) org.hibernate.event.def.DefaultLoadEventListener logs exception at info level
by Don Smith (JIRA)
org.hibernate.event.def.DefaultLoadEventListener logs exception at info level
-----------------------------------------------------------------------------
Key: HHH-2085
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2085
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.0.cr2
Environment: Hibernate 3.2.0.cr2, MySQL 4.0.18
Reporter: Don Smith
Priority: Minor
Prior to schema generation, accessing a persistent object throws an exception, as expected. The org.hibernate.event.def.DefaultLoadEventListener logs the exception at the info level, which just adds noise to the application console, and prevents application exception handling (in my case it's valid if the table doesn't exist, so I just want to catch the exception and continue). This log statement should be removed, or moved to a debug or trace level, so it won't show up in normal execution.
Code, from line 94 of org.hibernate.event.def.DefaultLoadEventListener:
catch(HibernateException e) {
log.info("Error performing load command", e);
throw e;
}
--
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
12 years
[Hibernate-JIRA] Created: (HHH-2052) org.hibernate.pretty.MessageHelper.collectionInfoString tries to cast wrong object to String, causes ClassCastException
by Tree 'Huggy Bear' Hugger (JIRA)
org.hibernate.pretty.MessageHelper.collectionInfoString tries to cast wrong object to String, causes ClassCastException
-----------------------------------------------------------------------------------------------------------------------
Key: HHH-2052
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2052
Project: Hibernate3
Type: Bug
Reporter: Tree 'Huggy Bear' Hugger
Attachments: bugtest.zip
Debug level logging attempted by MessageHelper falls over when constructing a loggable string for a mapped collection on the main entity.
Following the code in the stacktrace, I can see that MessageHelper expects the parent key for the collection relationship to be the primary key, but it is mapped to another field of a different type via a property-ref. Hence the ClassCastException below.
The work around is to set logging to INFO or higher.
I have also attached a pared-down zip with the maven 2 project containing the mappings and the unit test which fails.
The following JIRA issue may be the same thing:
http://opensource.atlassian.com/projects/hibernate/browse/ANN-298
The following messages on the Hib forum demonstrate other interest in this issue:
http://forum.hibernate.org/viewtopic.php?t=949913
http://forum.hibernate.org/viewtopic.php?t=956778
http://forum.hibernate.org/viewtopic.php?t=962471
java.lang.ClassCastException: com.nomadsoft.cortex.domain.country.basic.BasicCountry
at org.hibernate.type.StringType.toString(StringType.java:44)
at org.hibernate.type.NullableType.toLoggableString(NullableType.java:168)
at org.hibernate.pretty.MessageHelper.collectionInfoString(MessageHelper.java:284)
at org.hibernate.loader.Loader.readCollectionElement(Loader.java:972)
at org.hibernate.loader.Loader.readCollectionElements(Loader.java:635)
at org.hibernate.loader.Loader.getRowFromResultSet(Loader.java:580)
at org.hibernate.loader.Loader.doQuery(Loader.java:689)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:224)
at org.hibernate.loader.Loader.loadEntity(Loader.java:1785)
at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:47)
at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:41)
at org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:2730)
at org.hibernate.event.def.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:365)
at org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:346)
at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:123)
at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:177)
at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:87)
at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:862)
at org.hibernate.impl.SessionImpl.get(SessionImpl.java:799)
at org.hibernate.impl.SessionImpl.get(SessionImpl.java:792)
at org.springframework.orm.hibernate3.HibernateTemplate$1.doInHibernate(HibernateTemplate.java:452)
at org.springframework.orm.hibernate3.HibernateTemplate.execute(HibernateTemplate.java:366)
at org.springframework.orm.hibernate3.HibernateTemplate.get(HibernateTemplate.java:446)
at org.springframework.orm.hibernate3.HibernateTemplate.get(HibernateTemplate.java:440)
at com.nomadsoft.cortex.infrastructure.hibernate.HibernateCountryRepository.getById(HibernateCountryRepository.java:26)
at com.nomadsoft.cortex.domain.country.basic.BasicCountryService.getCountry(BasicCountryService.java:34)
etc etc
--
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
12 years, 3 months
[Hibernate-JIRA] Created: (HHH-2075) many-to-one in a properties element causes strange PropertyValueException on flush
by Josh Moore (JIRA)
many-to-one in a properties element causes strange PropertyValueException on flush
----------------------------------------------------------------------------------
Key: HHH-2075
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2075
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.0.cr4
Environment: HSQLDB
Hibernate r10478
Reporter: Josh Moore
Attachments: exception.txt, log.txt, properties.zip
Full test directory zip (org/hibernate/test/properties) attached. But to summarize, the following test will fail on flush after a simple merge. The exception thrown says that Pixels.sizeC is null -- though it's clearly set in the test case.
<code>
Image i = new Image();
Pixels p = new Pixels();
p.setSizeC(new Integer(2));
p.setImage(i); // This calls i.getPixels().add(p)
// i.setPixels(null); // This makes it work.
Session s = openSession();
Transaction t = s.beginTransaction();
// s.merge(i); // This makes it work.
p = (Pixels) s.merge(p); // This fails with the exception below.
t.commit();
s.close();
</code>
The properties element in question is:
<code>
<properties name="defaultPixelsTag">
<property name="defaultPixels" type="java.lang.Boolean"/>
<many-to-one name="image" class="Image" column="image"
not-null="true" unique="false" insert="true" update="true"
cascade="lock,merge,persist,replicate,refresh,save-update"
/>
</properties>
</code>
The reverse side is:
<code>
<set
name="pixels"
lazy="true"
inverse="true"
cascade="lock,merge,persist,replicate,refresh,save-update">
<key column="image" not-null="false"/>
<one-to-many class="Pixels"/>
</set>
</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
12 years, 5 months