[Hibernate-JIRA] Created: (HHH-6629) the argument of merge() got corrupted
by Vladimir Tsichevski (JIRA)
the argument of merge() got corrupted
-------------------------------------
Key: HHH-6629
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6629
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.6.7, 3.6.3
Environment: MySQL, Oracle
Reporter: Vladimir Tsichevski
The object passed to the EntityManager.merge() method sometimes got corrupted while the merge() is executed. This happens if
1. The entity has a @OneToMany field.
2. The @OneToMany field type is the same as or derivative of the owner type
3. The entity has a composite @Id
As the result, the owner object receives @Id fields from one of its @OneToMany field collection members.
This is due to that the parent object (owner) is sometimes used as the target template when children are merged in org.hibernate.type.ComponentType.replace() method (lines 460-462 in 3.6.7):
final Object result = target == null
? instantiate( owner, session )
: target;
which calls the org.hibernate.type.EmbeddedComponentType.instantiate method (lines 51-61):
public Object instantiate(Object parent, SessionImplementor session)
throws HibernateException {
final boolean useParent = parent!=null &&
//TODO: Yuck! This is not quite good enough, it's a quick
//hack around the problem of having a to-one association
//that refers to an embedded component:
super.getReturnedClass().isInstance(parent);
return useParent ? parent : super.instantiate(parent, session);
}
as you may see, if useParent is true, the parent object (owner) is used as the template to update children!
IMHO this must either be fixed or documentations shall say valuable objects must never be passed to merge()
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[Hibernate-JIRA] Created: (WEBSITE-7) HQL doc about setMaxResults and use of "join fetch" is confusing
by Anton Mostovoy (JIRA)
HQL doc about setMaxResults and use of "join fetch" is confusing
----------------------------------------------------------------
Key: WEBSITE-7
URL: http://opensource.atlassian.com/projects/hibernate/browse/WEBSITE-7
Project: Hibernate Website
Issue Type: Improvement
Reporter: Anton Mostovoy
Priority: Minor
The current [HQL documentation|http://docs.jboss.org/hibernate/core/3.6/reference/en-US/ht...] states:
"The fetch construct cannot be used in queries called using iterate() (though scroll() can be used). Fetch should be used together with setMaxResults() or setFirstResult(), as these operations are based on the result rows which usually contain duplicates for eager collection fetching, hence, the number of rows is not what you would expect. Fetch should also not be used together with impromptu with condition."
Test shows that in 3.6.5, setMaxResults() works correctly when "left join fetch" is used (although it appears to use client side limit, instead of 'rownum' in the sql query). Therefore, I believe the sentence about setMaxResults is very confusion and should be removed.
In docs for 3.2, it read "Note that the fetch construct may not be used in queries called using iterate() (though scroll() can be used). Nor should fetch be used together with setMaxResults() or setFirstResult() as these operations are based on the result rows, which usually contain duplicates for eager collection fetching, hence, the number of rows is not what you'd expect. "
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 4 months
[Hibernate-JIRA] Created: (HHH-3051) NPE while query.list on a Native SQL, using L2 cache
by Amit Kapoor (JIRA)
NPE while query.list on a Native SQL, using L2 cache
----------------------------------------------------
Key: HHH-3051
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3051
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.5
Environment: Hibernate 3.2.5ga
Database Oracle 9i
Jdk - 1.4.2_13
EHCache 1.2.3 / OsCache 2.1 both
Reporter: Amit Kapoor
I get an NPE when i try to execute a native query.
Below is the excerpt of the code that throws NPE:
String sqlQuery = "select emp_id, emp_first_name from employee_mt";
SQLQuery query = session.createSQLQuery(sqlQuery);
query.setCacheable(true).setCacheRegion("TEST_REGION");
query.addScalar("emp_id");
query.addScalar("emp_first_name");
List list = query.list();
query.list() throws the following NPE:
java.lang.NullPointerException
at org.hibernate.type.TypeFactory.disassemble(TypeFactory.java:451)
at org.hibernate.cache.StandardQueryCache.put(StandardQueryCache.java:83)
at org.hibernate.loader.Loader.putResultInQueryCache(Loader.java:2194)
at org.hibernate.loader.Loader.listUsingQueryCache(Loader.java:2138)
at org.hibernate.loader.Loader.list(Loader.java:2096)
at org.hibernate.loader.custom.CustomLoader.list(CustomLoader.java:289)
at org.hibernate.impl.SessionImpl.listCustomQuery(SessionImpl.java:1695)
at org.hibernate.impl.AbstractSessionImpl.list(AbstractSessionImpl.java:142)
at org.hibernate.impl.SQLQueryImpl.list(SQLQueryImpl.java:152)
at poc.hibernate.caching.QueryCaching.fireNativeSql(QueryCaching.java:112)
at poc.hibernate.caching.QueryCaching.fireQuery(QueryCaching.java:38)
at poc.hibernate.caching.QueryCaching.main(QueryCaching.java:27)
I tried tracing through the Hibernate code code and saw that the types[] in the at the time of execution of types[i].disassemble( row[i], session, owner ) (TypeFactory.disassemble()) was holding both the types as null.
However before reaching that piece of code CustomLoader.autoDiscoverTypes(resultset) had already resolved the resultTypes to appropriate values.
Hope this helps.
--
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
13 years, 4 months
[Hibernate-JIRA] Created: (HHH-6020) Move to JBossTS caused some test failures in hibernate-envers
by Steve Ebersole (JIRA)
Move to JBossTS caused some test failures in hibernate-envers
-------------------------------------------------------------
Key: HHH-6020
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6020
Project: Hibernate Core
Issue Type: Bug
Components: envers
Reporter: Steve Ebersole
Assignee: Adam Warski
Fix For: 4.0.0.Alpha2
Specifically there is 1 tests that fails in both configurations for a total of 2 failures. The test class is {{org.hibernate.envers.test.integration.jta.JtaTransaction}}. The failure says:
{noformat}
null
org.hibernate.engine.jdbc.internal.JdbcServicesImpl.configure(JdbcServicesImpl.java:110)
at org.hibernate.service.internal.ServiceInitializer.configureService(ServiceInitializer.java:141)
at org.hibernate.service.internal.ServiceInitializer.initializeService(ServiceInitializer.java:108)
at org.hibernate.service.internal.ServiceRegistryImpl.getServiceInternal(ServiceRegistryImpl.java:119)
at org.hibernate.service.internal.proxy.javassist.ServiceProxyFactoryImpl$ServiceProxyMethodInterceptor.invoke(ServiceProxyFactoryImpl.java:114)
at org.hibernate.engine.jdbc.spi.JdbcServices_$$_javassist_0.getExtractedMetaDataSupport(JdbcServices_$$_javassist_0.java)
at org.hibernate.cfg.SettingsFactory.buildSettings(SettingsFactory.java:77)
at org.hibernate.cfg.Configuration.buildSettingsInternal(Configuration.java:2848)
at org.hibernate.cfg.Configuration.buildSettings(Configuration.java:2844)
at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1825)
at org.hibernate.ejb.EntityManagerFactoryImpl.<init>(EntityManagerFactoryImpl.java:77)
at org.hibernate.ejb.Ejb3Configuration.buildEntityManagerFactory(Ejb3Configuration.java:888)
at org.hibernate.envers.test.AbstractEntityTest.init(AbstractEntityTest.java:123)
at org.hibernate.envers.test.AbstractEntityTest.init(AbstractEntityTest.java:97)
...
{noformat}
JdbcServicesImpl.java:110 is a simple attempt to use the {{java.sql.Connection}} returned by the configured {{org.hibernate.service.jdbc.connections.spi.ConnectionProvider}}:
{code}
Connection conn = connectionProvider.getConnection();
try {
DatabaseMetaData meta = conn.getMetaData(); // <- this is line 110
...
{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
13 years, 4 months