[Hibernate-JIRA] Created: (HHH-2236) Lazy property + setReadOnly + Instrumented classes results in NullPointerException when accessing lazy property
by Max Rydahl Andersen (JIRA)
Lazy property + setReadOnly + Instrumented classes results in NullPointerException when accessing lazy property
---------------------------------------------------------------------------------------------------------------
Key: HHH-2236
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2236
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.0.ga
Reporter: Max Rydahl Andersen
<property name="data" lazy="true">
will give NPE on instrumented classes if you do :
p1 = (Problematic) s.createQuery( "from Problematic" ).setReadOnly(true ).list().get( 0 );
p1.getData(); // NPE's because of missing snapshot
java.lang.NullPointerException
at org.hibernate.persister.entity.AbstractEntityPersister.initializeLazyProperty(AbstractEntityPersister.java:856)
at org.hibernate.persister.entity.AbstractEntityPersister.initializeLazyPropertiesFromDatastore(AbstractEntityPersister.java:786)
at org.hibernate.persister.entity.AbstractEntityPersister.initializeLazyProperty(AbstractEntityPersister.java:750)
at org.hibernate.intercept.AbstractFieldInterceptor.intercept(AbstractFieldInterceptor.java:75)
at org.hibernate.intercept.cglib.FieldInterceptorImpl.readObject(FieldInterceptorImpl.java:75)
at org.hibernate.test.instrument.domain.Problematic.$cglib_read_bytes(Problematic.java)
at org.hibernate.test.instrument.domain.Problematic.getData(Problematic.java:41)
--
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
19 years, 5 months
[Hibernate-JIRA] Commented: (HHH-1460) Inconsistent behavior when using Session.get() with multiple subclasses
by Olaf Lenzmann (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1460?page=c... ]
Olaf Lenzmann commented on HHH-1460:
------------------------------------
I was a bit rash - a wrapper a la exists() cannot catch the ClassCastException if it's a generic method (generics don't compile to code that depends on the parameter classes, so the actual class cast is done by the VM in the calling non-generic method), but it can use Class.isAssignableFrom() to check the type of the returned entity. For EJB3, something like
public <EntityType> EntityType exists( Class<EntityType> entityClass, Object id ) {
final EntityType entity = entityManager.find( entityClass, id );
if( entity != null && entityClass.isAssignableFrom( entity.getClass() ) )
return true;
else
return false;
}
> Inconsistent behavior when using Session.get() with multiple subclasses
> -----------------------------------------------------------------------
>
> Key: HHH-1460
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1460
> Project: Hibernate3
> Type: Bug
> Components: core
> Versions: 3.1.2
> Environment: Hibernate 3.1.2
> HSQLDB 1.8.0.2
> Java 1.5.0_05-b05
> Reporter: Seth Fitzsimmons
> Attachments: ClassCastException.zip
>
>
> Session.get() loads a cached instance of an alternate subclass with the same PK after that subclass has been loaded directly (throwing a ClassCastException where null was expected). When attempting to load it without prior loading, null is returned, as expected.
> Client and Partner both extend person and have discriminator values of 1 and 2, respectively. There is a single entry in the database (a Client) with a PK of 0.
> This should be null:
> Partner partner = (Partner) getSession().get(Partner.class, 0);
> assertNull(partner);
> It is. However, if the Client is loaded first, Hibernate will attempt to return a Partner (as a Client) where it should not exist:
> Client client = (Client) getSession().get(Client.class, 0);
> assertNotNull(client);
>
> // this should be null, not return a Client object (resulting in a ClassCastException)
> Partner partner = (Partner) getSession().get(Partner.class, 0);
> assertNull(partner);
--
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
19 years, 5 months
[Hibernate-JIRA] Commented: (HHH-1460) Inconsistent behavior when using Session.get() with multiple subclasses
by Olaf Lenzmann (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1460?page=c... ]
Olaf Lenzmann commented on HHH-1460:
------------------------------------
IMHO, this should return null. The current behavior is inconsistent and confusing at best - effectively it makes the behavior of the ORM statefully dependent on what read-access has been done in the same transaction before find() is called. This means that you cannot rely on getting null if you try to find an entity with an id that does exist for the type, but you have to be prepared to swallow an exception. Since something like a method exists( Class type, Object id ) does not exist (at least not in EJB3, where we ran into this behavior), checking for the existence of an entity requires us to write wrappers that redirect class-cast exceptions to a false result.
If you really believe that this makes sense, please document this behavior clearly! The very simple fix would be to make DefaultLoadEventListener.loadFromSessionCache() check the actual type of the entity it finds in the cache (if that's possible based on the data at hand). Alternatively, the current behavior would be perfectly ok if there was an exists() method that works properly.
> Inconsistent behavior when using Session.get() with multiple subclasses
> -----------------------------------------------------------------------
>
> Key: HHH-1460
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1460
> Project: Hibernate3
> Type: Bug
> Components: core
> Versions: 3.1.2
> Environment: Hibernate 3.1.2
> HSQLDB 1.8.0.2
> Java 1.5.0_05-b05
> Reporter: Seth Fitzsimmons
> Attachments: ClassCastException.zip
>
>
> Session.get() loads a cached instance of an alternate subclass with the same PK after that subclass has been loaded directly (throwing a ClassCastException where null was expected). When attempting to load it without prior loading, null is returned, as expected.
> Client and Partner both extend person and have discriminator values of 1 and 2, respectively. There is a single entry in the database (a Client) with a PK of 0.
> This should be null:
> Partner partner = (Partner) getSession().get(Partner.class, 0);
> assertNull(partner);
> It is. However, if the Client is loaded first, Hibernate will attempt to return a Partner (as a Client) where it should not exist:
> Client client = (Client) getSession().get(Client.class, 0);
> assertNotNull(client);
>
> // this should be null, not return a Client object (resulting in a ClassCastException)
> Partner partner = (Partner) getSession().get(Partner.class, 0);
> assertNull(partner);
--
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
19 years, 5 months
[Hibernate-JIRA] Commented: (HHH-1258) startup time improvements
by Max Rydahl Andersen (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1258?page=c... ]
Max Rydahl Andersen commented on HHH-1258:
------------------------------------------
Pankaj - I would please ask you to create a seperate issue with the patch you applied instead of adding a jar file.
This bug should be used to link to it.
Thank you.
> startup time improvements
> -------------------------
>
> Key: HHH-1258
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1258
> Project: Hibernate3
> Type: Improvement
> Components: core
> Versions: 3.1 rc3
> Reporter: Max Rydahl Andersen
> Assignee: Max Rydahl Andersen
> Attachments: SessionFactoryImpl.java, SessionFactoryImpl.patch
>
>
> while doing some basic startup perf testing the following were found - this issue is mainly to track what I find, and then fix it:
> Initial tests where 100 classes, 30 sec for buildSessionFactory
> setting hibernate.cglib.use_reflection_optimizer false and it is 10 sec for buildSessionFactory.
> (maybe we should autodetect which jdk we are running on and disable it per default for 1.4/1.5 - needs to validate runtime impact)
> Another (22%) time stealer is the discovery of getter/setters - in worst case it iterates over all declared methods per property.
> (alternatively we could cache/sort this list or make a more efficient implementation if a class only contain default property accessors)
> Other 20% of the time is done in net.sf.cglib related classes for build time enhancement.
> The rest of the time is Configuration creation (can be cached) and other iteration code.
> (p.s. don't take the % numbers as hard values - these are definitly affected by how many methods/classes you have; this underlying tests
> is done on pojos with a "high" method count (approx 100)
--
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
19 years, 5 months
[Hibernate-JIRA] Updated: (HHH-1258) startup time improvements
by Max Rydahl Andersen (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1258?page=all ]
Max Rydahl Andersen updated HHH-1258:
-------------------------------------
Attachment: (was: cplhibernate.jar)
> startup time improvements
> -------------------------
>
> Key: HHH-1258
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1258
> Project: Hibernate3
> Type: Improvement
> Components: core
> Versions: 3.1 rc3
> Reporter: Max Rydahl Andersen
> Assignee: Max Rydahl Andersen
> Attachments: SessionFactoryImpl.java, SessionFactoryImpl.patch
>
>
> while doing some basic startup perf testing the following were found - this issue is mainly to track what I find, and then fix it:
> Initial tests where 100 classes, 30 sec for buildSessionFactory
> setting hibernate.cglib.use_reflection_optimizer false and it is 10 sec for buildSessionFactory.
> (maybe we should autodetect which jdk we are running on and disable it per default for 1.4/1.5 - needs to validate runtime impact)
> Another (22%) time stealer is the discovery of getter/setters - in worst case it iterates over all declared methods per property.
> (alternatively we could cache/sort this list or make a more efficient implementation if a class only contain default property accessors)
> Other 20% of the time is done in net.sf.cglib related classes for build time enhancement.
> The rest of the time is Configuration creation (can be cached) and other iteration code.
> (p.s. don't take the % numbers as hard values - these are definitly affected by how many methods/classes you have; this underlying tests
> is done on pojos with a "high" method count (approx 100)
--
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
19 years, 5 months
[Hibernate-JIRA] Updated: (HHH-1258) startup time improvements
by Pankaj Gupta (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1258?page=all ]
Pankaj Gupta updated HHH-1258:
------------------------------
Attachment: cplhibernate.jar
Hi,
Attached is the jar file for version 3.0.4 which can be used for above mentioned improvement.
> startup time improvements
> -------------------------
>
> Key: HHH-1258
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1258
> Project: Hibernate3
> Type: Improvement
> Components: core
> Versions: 3.1 rc3
> Reporter: Max Rydahl Andersen
> Assignee: Max Rydahl Andersen
> Attachments: SessionFactoryImpl.java, SessionFactoryImpl.patch, cplhibernate.jar
>
>
> while doing some basic startup perf testing the following were found - this issue is mainly to track what I find, and then fix it:
> Initial tests where 100 classes, 30 sec for buildSessionFactory
> setting hibernate.cglib.use_reflection_optimizer false and it is 10 sec for buildSessionFactory.
> (maybe we should autodetect which jdk we are running on and disable it per default for 1.4/1.5 - needs to validate runtime impact)
> Another (22%) time stealer is the discovery of getter/setters - in worst case it iterates over all declared methods per property.
> (alternatively we could cache/sort this list or make a more efficient implementation if a class only contain default property accessors)
> Other 20% of the time is done in net.sf.cglib related classes for build time enhancement.
> The rest of the time is Configuration creation (can be cached) and other iteration code.
> (p.s. don't take the % numbers as hard values - these are definitly affected by how many methods/classes you have; this underlying tests
> is done on pojos with a "high" method count (approx 100)
--
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
19 years, 5 months
[Hibernate-JIRA] Created: (HHH-2178) When the sql statement submited to create the PreparedStatement contains comments, MySQL misunderstand it (and doubles the parameter count).
by Diogenes Gomes (JIRA)
When the sql statement submited to create the PreparedStatement contains comments, MySQL misunderstand it (and doubles the parameter count).
--------------------------------------------------------------------------------------------------------------------------------------------
Key: HHH-2178
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2178
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.0.ga
Environment: MySQL 3.2.0
Reporter: Diogenes Gomes
Priority: Trivial
When I used the following Hibernate properties:
hibernate.format_sql=true
hibernate.use_sql_comments=true
I found a bug in QueryLoader.java in method prepareQueryStatement:
...
sql = preprocessSQL( sql, queryParameters, dialect );
PreparedStatement st = null;
if (callable) {
st = session.getBatcher()
.prepareCallableQueryStatement( sql, scroll || useScrollableResultSetToSkip, scrollMode );
}
else {
st = session.getBatcher()
.prepareQueryStatement( sql, scroll || useScrollableResultSetToSkip, scrollMode );
}
...
Before running preprocessSQL, the value of the local variable 'sql' was: "select ... from ... where formulario0_.ffw_nome=?"
After running preprocessSQL, the value of 'sql' was: "/* from ... where form.nome = ? */ select ... from ... where formulario0_.ffw_nome=?"
The value of st.parameterCount after running session.getBatcher().prepareQueryStatement(...) was 2 (may be because of the double ? in the sql statement). And I got a SQLException: "No value specified for parameter 2".
When I set both variables to false, it runs ok. The st.parameterCount is 1 and no exception.
--
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
19 years, 5 months
[Hibernate-JIRA] Created: (HHH-2233) Rethrow HibernateException instead of "catch and log only" SQLException.
by Mark Gorokhov (JIRA)
Rethrow HibernateException instead of "catch and log only" SQLException.
------------------------------------------------------------------------
Key: HHH-2233
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2233
Project: Hibernate3
Type: Improvement
Components: core
Versions: 3.2.0.ga
Environment: Hibernate v 3.2.0, October 16, 2006,
HSQLDB 1.8.0.7 (Using In-process mode)
Reporter: Mark Gorokhov
Steps to reproduce:
AnnotationConfiguration ac = new AnnotationConfiguration();
ac.addAnnotatedClass(Foo.class); // with annotations
ac.setProperty(Environment.URL, "jdbc:hsqldb:file:C:\\abc\\dbTest");
ac.setProperty(Environment.DRIVER, "org.hsqldb.jdbcDriver");
ac.setProperty(Environment.USER, "wrong_user"); // note: not "sa" user
ac.setProperty(Environment.PASS, "bad");
ac.setProperty(Environment.DIALECT, "org.hibernate.dialect.HSQLDialect");
ac.setProperty(Environment.CACHE_PROVIDER,"org.hibernate.cache.NoCacheProvider");
ac.setProperty(Environment.HBM2DDL_AUTO, "update"); // creates missing DB
SessionFactory sessionFactory = ac.buildSessionFactory();
There are *logged* SQLExceptions "User not found" but ac.buildSessionFactory() does not *throw* any exceptions. SessionFactory is not functional but there are no exceptions thrown!
Probably there are other places in the code when exception is logged but not rethrown. Exception in a log is useless because client code does not know about exception and does not report problem to a user and does not make attempts to recover.
--
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
19 years, 5 months