[Hibernate-JIRA] Created: (HHH-2470) Use of session.createSQLQuery causes memory leak
by Bjørn Bjerkeli (JIRA)
Use of session.createSQLQuery causes memory leak
-------------------------------------------------
Key: HHH-2470
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2470
Project: Hibernate3
Type: Bug
Components: query-sql
Versions: 3.1.3
Environment: Win XP, Oracle 10g, Java 1.4.2
Reporter: Bjørn Bjerkeli
Attachments: TestCase.zip
NativeSQLQuerySpecification fails to properly implement equals and hashcode caused by lacking implementation of hashCode and equals in all SQLQueryReturn implementations and SQLQueryScalarReturn which are members of NativeSQLQuerySpecification. I can see that NativeSQLQuerySpecification has been changed in 3.2, but the problem is still there.
NativeSQLQuerySpecification instances are used as keys for retrieving and caching NativeSQLQueryPlan instances.
This causes the caching-mechanism to be pretty useless when Queries created by session.createSQLQuery because new entries will be added all the time in the QueryPlanCache and the SoftLimitMRUCache member.
So far so good, the more serious problem that is caused by this is stems from the implementation of SoftLimitMRUCache which again uses LRUMap in commons-collection. The put - method of the cache is not treadsafe, and that causes the following fragment in LRUMap to allow the map to grow beyond its maximumSize. That is bacause the containsKey method will return an incorrect result when concurrently updating the map.
public Object put( Object key, Object value ) {
int mapSize = size();
Object retval = null;
if ( mapSize >= maximumSize ) {
// don't retire LRU if you are just
// updating an existing key
if (!containsKey(key)) {
// lets retire the least recently used item in the cache
removeLRU();
}
}
retval = super.put(key,value);
return retval;
}
I have included a test-case that demonstrates:
1) Wrong implementation of equals and hashCode in NativeSQLQuerySpecification
2) Concurrent use of LRUMap causes the map to grow beyound it's max limit
3) Concurrent execution of session.createSQLQuery causes memory leak due to 1) and 2)
I would be more than happy to contribute to get this fixed. Just let me know.
--
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, 5 months
[Hibernate-JIRA] Created: (HHH-3221) Cascading performance problems when session contains many entities
by Yves Galante (JIRA)
Cascading performance problems when session contains many entities
------------------------------------------------------------------
Key: HHH-3221
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3221
Project: Hibernate3
Issue Type: Improvement
Components: core
Affects Versions: 3.3.0.CR1, 3.2.6, 3.2.5
Reporter: Yves Galante
Attachments: patchCascading.patch, SaveTest.zip
When session contains many entities, performence of cascading become very slow.
For each collection element the whole persistence context is searched (by StatefulPersistenceContext#getIndexInOwner() and StatefulPersistenceContext#getOwnerId) and its even searched twice when the collection is an indexed collection.
This patch optimize cascading operation by caching relation parent-child on a map.
eventSource.getPersistenceContext().addChildParent(child, parent);
action.cascade(eventSource, child, entityName, anything, isCascadeDeleteEnabled);
eventSource.getPersistenceContext().removeChildParent(child);
The test case save and flush 10 * 551 objects.
Before patch save object with cascading is more slow when session size grows.
After patch time of save stay same at each loop.
Output of the test case before the patch :
Save took 449 ms
Save took 669 ms
Save took 1042 ms
Save took 1464 ms
Save took 2481 ms
Save took 2741 ms
Save took 3807 ms
Save took 4344 ms
Save took 4975 ms
Save took 5251 ms
Total took 30906 ms
Output after the patch
Save took 445 ms
Save took 144 ms
Save took 164 ms
Save took 108 ms
Save took 93 ms
Save took 93 ms
Save took 93 ms
Save took 94 ms
Save took 91 ms
Save took 89 ms
Total took 4905 ms
--
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, 5 months
[Hibernate-JIRA] Created: (HHH-2339) merge instumented class fails
by Alexey Romanchuk (JIRA)
merge instumented class fails
-----------------------------
Key: HHH-2339
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2339
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.1, 3.2.0.ga
Environment: Hibernate 3.2.1 (tested with 3.2.0 too)
Postgresql 8.1.4
Reporter: Alexey Romanchuk
Priority: Blocker
When we try to merge instrumented detached entity with lazy no-proxy many-to-one association we have org.hibernate.LazyInitializationException.
It occurs because cascade try to process all associations in Cascade class, but object disconected from session and can not obtaion lazy property.
If classes are not instrumented all works ok.
Why merge action does not have overrided performOnLazyProperty mathod to prevent fetching lazy properties?
Here it is small example that illustates problem.
===MAPPING===
<hibernate-mapping>
<class name="Client" table="test_client">
<id name="id" column="id" type="long">
<generator class="sequence">
<param name="sequence">test_seq</param>
</generator>
</id>
<property name="name" column="name"/>
<many-to-one name="info" class="LoginInfo" lazy="no-proxy" column="info_id" cascade="merge,evict"/>
</class>
<class name="LoginInfo" table="test_login_info">
<id name="id" column="id" type="long">
<generator class="sequence">
<param name="sequence">test_seq</param>
</generator>
</id>
<property name="login" column="login"/>
<property name="pass" column="pass"/>
</class>
</hibernate-mapping>
===JAVA===
===DOMAIN===
public class Client
{
private long id;
private String name;
private LoginInfo info;
//getters and setters
}
public class LoginInfo
{
private long id;
private String login;
private String pass;
//getters and setters
}
===USAGE===
public class Main
{
public static void main( String[] args )
{
Session s1 = sf.openSession();
s1.beginTransaction();
Client c = ( Client ) s1.get( Client.class, 2l );
s1.flush();
s1.getTransaction().commit();
s1.close();
Session s2 = sf.openSession();
s2.beginTransaction();
c = ( Client ) s2.merge( c );
s2.flush();
s2.getTransaction().commit();
s2.close();
}
}
==STACKTRACE===
org.hibernate.LazyInitializationException: session is not connected
at org.hibernate.intercept.AbstractFieldInterceptor.intercept(AbstractFieldInterceptor.java:67)
at org.hibernate.intercept.cglib.FieldInterceptorImpl.readObject(FieldInterceptorImpl.java:75)
at Client.$cglib_read_info(Client.java)
at Client.getInfo(Client.java:12)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.hibernate.property.BasicPropertyAccessor$BasicGetter.get(BasicPropertyAccessor.java:145)
at org.hibernate.tuple.entity.AbstractEntityTuplizer.getPropertyValue(AbstractEntityTuplizer.java:277)
at org.hibernate.persister.entity.AbstractEntityPersister.getPropertyValue(AbstractEntityPersister.java:3529)
at org.hibernate.engine.Cascade.cascade(Cascade.java:130)
at org.hibernate.event.def.DefaultMergeEventListener.cascadeOnMerge(DefaultMergeEventListener.java:407)
at org.hibernate.event.def.DefaultMergeEventListener.entityIsDetached(DefaultMergeEventListener.java:266)
at org.hibernate.event.def.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:120)
at org.hibernate.event.def.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:53)
at org.hibernate.impl.SessionImpl.fireMerge(SessionImpl.java:677)
at org.hibernate.impl.SessionImpl.merge(SessionImpl.java:661)
at org.hibernate.impl.SessionImpl.merge(SessionImpl.java:665)
at Main.main(Main.java:56)
--
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, 6 months
[Hibernate-JIRA] Created: (HHH-2388) Insert w/ identity column fails on Sybase but no exception occurs
by Tim Morrow (JIRA)
Insert w/ identity column fails on Sybase but no exception occurs
-----------------------------------------------------------------
Key: HHH-2388
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2388
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.1
Environment: Hibernate 3.2.1.GA with annotations
Sybase jConnect 6.05 JDBC driver
Sybase ASE 15 database
Reporter: Tim Morrow
I have a scenario where storing a new entity fails (i.e. the row is not inserted) but Hibernate does not realize this. No exceptions are thrown. Later, this leads to AssertionFailures (if two such entities fail in the same session - they both have the same PK).
The problem specifically occurs with a table that has a numeric column with precision (e.g. numeric(10,4)) and an identity column when using Sybase ASE.
==========
To reproduce:
1. Use Sybase jConnect 6.05 JDBC driver with Sybase ASE 15 database.
2. Define an Entity with a long ID and BigDecimal numeric column.
3. Create a corresponding table with an identity column and numeric(10, 4) column.
For example:
hibernate.MyEntity.java:
-----------------------------------------
package hibernate;
import java.math.BigDecimal;
import javax.persistence.Column;
import javax.persistence.Entity;
import javax.persistence.GeneratedValue;
import javax.persistence.GenerationType;
import javax.persistence.Id;
import javax.persistence.Table;
import org.hibernate.validator.NotNull;
@Entity
@Table(name = "z_tim_test")
public class MyEntity {
private BigDecimal cost;
private long id;
public MyEntity() {}
@Column(columnDefinition = "numeric(10,4)")
@NotNull public final BigDecimal getCost() {
return cost;
}
@GeneratedValue(strategy = GenerationType.AUTO)
@Id public final long getId() {
return id;
}
public final void setCost(BigDecimal cost) {
this.cost = cost;
}
public final void setId(long id) {
this.id = id;
}
}
Table:
-----------------------------------------
CREATE TABLE z_tim_test
(
id numeric(19) PRIMARY KEY not null,
cost numeric(10,4) not null
);
4. Write some code that stores a new entity and tries to load it:
MyEntity myEntity = new MyEntity();
myEntity.setCost(new BigDecimal("123.12345"));
session.save(myEntity);
session.flush();
session.clear();
List<MyEntity> results = session.createCriteria(MyEntity.class).list();
if (results.size() != 1) {
throw new IllegalStateException("Expected 1 result");
}
This test will throw the IllegalStateException because the row was not persisted and no errors occurred.
Reason:
* Sybase does not thrown any SQLException when you try and persist a numeric value whose scale exceeds that defined on the column. Instead, it returns an updateCount of zero and an identity column value of zero.
* Hibernate does not check the updateCount after executing the statement when using an Identity column. The offending code is in:
org.hibernate.id.IdentityGenerator$InsertSelectDelegate
public Serializable executeAndExtract(PreparedStatement insert) throws SQLException {
if ( !insert.execute() ) {
while ( !insert.getMoreResults() && insert.getUpdateCount() != -1 ) {
// do nothing until we hit the rsult set containing the generated id
}
}
ResultSet rs = insert.getResultSet();
try {
return IdentifierGeneratorFactory.getGeneratedIdentity( rs, persister.getIdentifierType() );
}
finally {
rs.close();
}
}
It ignores the updateCount.
The net result is that the object is assigned a PK value of zero. Hibernate continues. My applicaiton is unaware that the row failed to insert.
Solution:
It would seem to me replacing the above code with:
if (!insert.execute()) {
if (insert.getUpdateCount() < 1) {
throw new HibernateException("No update occurred");
}
while (!insert.getMoreResults()) {
// do nothing until we hit the rsult set containing the generated id
}
}
Would take care of the 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, 6 months
[Hibernate-JIRA] Created: (HHH-3002) database field name 'version' causes ClassCastException while building session factory
by Patrick Burke (JIRA)
database field name 'version' causes ClassCastException while building session factory
--------------------------------------------------------------------------------------
Key: HHH-3002
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3002
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.5
Environment: Hibernate 3.2.5, Java 1.6.0_03, MySQL 5.0.41
Reporter: Patrick Burke
Attachments: out.hib4
When a database table contains a field named 'version', like his one:
DROP TABLE IF EXISTS `tester`.`software_package`;
CREATE TABLE `tester`.`software_package` (
`software_id` int(11) NOT NULL auto_increment,
`version` varchar(100) default NULL,
`name` varchar(100) default NULL,
`root_file_id` int(11) default NULL,
PRIMARY KEY (`software_id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1;
The following error is thrown:
[java] Initial SessionFactory creation failed.java.lang.ClassCastException: org.hibernate.type.StringType cannot be cast to org.hibernate.type.VersionType
[java] Exception in thread "main" java.lang.ExceptionInInitializerError
[java] at util.HibernateUtil.<clinit>(Unknown Source)
[java] at events.EventManager.listNodes(Unknown Source)
[java] at events.EventManager.main(Unknown Source)
[java] Caused by: java.lang.ClassCastException: org.hibernate.type.StringType cannot be cast to org.hibernate.type.VersionType
[java] at org.hibernate.tuple.PropertyFactory.buildVersionProperty(PropertyFactory.java:84)
[java] at org.hibernate.tuple.entity.EntityMetamodel.<init>(EntityMetamodel.java:168)
[java] at org.hibernate.persister.entity.AbstractEntityPersister.<init>(AbstractEntityPersister.java:434)
[java] at org.hibernate.persister.entity.SingleTableEntityPersister.<init>(SingleTableEntityPersister.java:109)
[java] at org.hibernate.persister.PersisterFactory.createClassPersister(PersisterFactory.java:55)
[java] at org.hibernate.impl.SessionFactoryImpl.<init>(SessionFactoryImpl.java:226)
[java] at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1294)
[java] ... 3 more
--
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, 6 months
[Hibernate-JIRA] Created: (HHH-3045) Duplicated column aliases in scalar query
by Anderson Souza (JIRA)
Duplicated column aliases in scalar query
-----------------------------------------
Key: HHH-3045
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3045
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.5
Environment: Hibernate 3.2.4SP1, 3.2.5GA
Oracle 10g
Reporter: Anderson Souza
Priority: Critical
Attachments: ddl-tables.sql, dominio.zip
The HQL bellow works fine, but when I add a call to a funcion in the select clause the SQL generated has duplicated aliases and it generate error on query execution, because the query is paginated.
{code}
select a
from Area a
inner join fetch a.horarioPadrao
left outer join fetch a.horarioTemporario as hrtemp
{code}
The SQL generated for this query is:
{code}
select * from (
select area0_.cod_local as cod1_15_0_,
horarioare1_.cod_area as cod1_6_1_,
horarioare2_.cod_area as cod1_7_2_,
area0_.des_local as des2_15_0_,
area0_.sig_local as sig3_15_0_,
area0_.flg_extinto as flg4_15_0_,
horarioare1_.hr_hora_ini as hr2_6_1_,
horarioare1_.hr_hora_fim as hr3_6_1_,
horarioare1_.flg_fim_semana as flg4_6_1_,
horarioare2_.hr_hora_ini as hr2_7_2_,
horarioare2_.hr_hora_fim as hr3_7_2_,
horarioare2_.flg_fim_semana as flg4_7_2_,
horarioare2_.dat_ini_vigencia as dat5_7_2_,
horarioare2_.dat_fim_vigencia as dat6_7_2_
from esq_fp.tb_local area0_
inner join tb_horario_local_padrao horarioare1_ on area0_.cod_local=horarioare1_.cod_area
left outer join tb_horario_local_temporario horarioare2_ on area0_.cod_local=horarioare2_.cod_area
where 1=1
order by area0_.sig_local )
where rownum <= ?
{code}
The scalar HQL query that generate duplicated column names is:
{code}
select a, count(*)
from Area a
inner join fetch a.horarioPadrao
left outer join fetch a.horarioTemporario as hrtemp
{code}
The SQL generated is:
{code}
select * from (
select area0_.cod_local as col_0_0_,
count(*) as col_1_0_,
horarioare1_.cod_area as cod1_6_1_,
horarioare2_.cod_area as cod1_7_2_,
area0_.cod_local as cod1_15_0_,
horarioare1_.cod_area as cod1_6_1_,
horarioare2_.cod_area as cod1_7_2_,
area0_.des_local as des2_15_0_,
area0_.sig_local as sig3_15_0_,
area0_.flg_extinto as flg4_15_0_,
horarioare1_.hr_hora_ini as hr2_6_1_,
horarioare1_.hr_hora_fim as hr3_6_1_,
horarioare1_.flg_fim_semana as flg4_6_1_,
horarioare2_.hr_hora_ini as hr2_7_2_,
horarioare2_.hr_hora_fim as hr3_7_2_,
horarioare2_.flg_fim_semana as flg4_7_2_,
horarioare2_.dat_ini_vigencia as dat5_7_2_,
horarioare2_.dat_fim_vigencia as dat6_7_2_
from esq_fp.tb_local area0_
inner join tb_horario_local_padrao horarioare1_ on area0_.cod_local=horarioare1_.cod_area
left outer join tb_horario_local_temporario horarioare2_ on area0_.cod_local=horarioare2_.cod_area
where 1=1
order by area0_.sig_local )
where rownum <= ?
{code}
As you can see the aliases cod1_6_1_ and cod1_7_2_ are repeated and this repetition breaks the paginated query, beacause the main query appears in the from clause.
The HBM's and classes are attached.
--
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, 6 months
[Hibernate-JIRA] Created: (HHH-3058) When using native sql query and multiple selects with setMaxResults, Hibernate inserts the TOP statement in the first query
by Sean Blaes (JIRA)
When using native sql query and multiple selects with setMaxResults, Hibernate inserts the TOP statement in the first query
---------------------------------------------------------------------------------------------------------------------------
Key: HHH-3058
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3058
Project: Hibernate3
Issue Type: Bug
Components: query-sql
Affects Versions: 3.2.4.sp1
Environment: Hibernate 3.2.4sp1, Microsoft SQL Server
Reporter: Sean Blaes
Priority: Minor
When using a query similar to the following:
DECLARE @SUB_TABLE TABLE(
ID INT
)
INSERT INTO @SUB_TABLE
SELECT ID
FROM FOO
SELECT *
FROM BAR
INNER JOIN @SUB_TABLE
ON ...
Then if I call setMaxResults(100) on the query object. It inserts "TOP 100" in the first query, which isn't really what would be expected. Since the second SELECT actually consists of the data that will be returned, the TOP 100 statement should go there.
I'd expect it's an easy fix. Just start your search for SELECT from the bottom rather than the top. However, I guess you have to make sure you're not hitting a subquery of a larger select either... I may try cooking up a patch this weekend for this if I can find the time, and I'll attach it to this issue if I do.
--
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, 6 months
[Hibernate-JIRA] Created: (HHH-1989) Deleted object remains referenced in 2nd level cache collections
by Justin Haddad (JIRA)
Deleted object remains referenced in 2nd level cache collections
----------------------------------------------------------------
Key: HHH-1989
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1989
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.0.cr2
Environment: Spring 1.2.8, Hibernate 3.2, Postgres 8.0.3
Reporter: Justin Haddad
This problem seems identical to issue NH-678. I have enabled caching for an one-to-many association. I use Ehcache. I have a test in which I load the parent object along with its collection. Both the parent and the collection wind up in the 2nd level cache. I then delete an object that is in the collection, not by removing it from the collection, but rather by doing a delete on the object itself. After deleting, I try to reload the parent and get the following exception (User#3102 is the deleted object):
aused by: org.hibernate.ObjectNotFoundException: No row with the given identifier exists: [com.bluenotenetworks.common.management.sm.User#3102]
at org.hibernate.impl.SessionFactoryImpl$1.handleEntityNotFound(SessionFactoryImpl.java:372)
at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:128)
at org.hibernate.event.def.DefaultLoadEventListener.proxyOrLoad(DefaultLoadEventListener.java:178)
at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:86)
at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:871)
at org.hibernate.impl.SessionImpl.internalLoad(SessionImpl.java:839)
at org.hibernate.type.EntityType.resolveIdentifier(EntityType.java:266)
at org.hibernate.type.ManyToOneType.assemble(ManyToOneType.java:177)
at org.hibernate.collection.PersistentSet.initializeFromCache(PersistentSet.java:101)
at org.hibernate.cache.entry.CollectionCacheEntry.assemble(CollectionCacheEntry.java:35)
at org.hibernate.event.def.DefaultInitializeCollectionEventListener.initializeCollectionFromCache(DefaultInitializeCollectionEventListener.java:130)
at org.hibernate.event.def.DefaultInitializeCollectionEventListener.onInitializeCollection(DefaultInitializeCollectionEventListener.java:48)
at org.hibernate.impl.SessionImpl.initializeCollection(SessionImpl.java:1705)
(continues on)
I stepped through the code in the debugger and can see that the object's ID (3102 in this case) remains in the cached collection even after the deletion.
--
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, 6 months
[Hibernate-JIRA] Created: (HHH-3075) Should be possible to register UserTypes for known property types (classes) in configuration
by Martin Probst (JIRA)
Should be possible to register UserTypes for known property types (classes) in configuration
--------------------------------------------------------------------------------------------
Key: HHH-3075
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3075
Project: Hibernate3
Issue Type: Improvement
Components: core
Environment: n/a
Reporter: Martin Probst
Priority: Minor
Currently, when persisting primitive properties of a class that are not known to Hibernate, there are only cumbersome ways to tell Hibernate that a certain UserType should be used. Good example is Joda Time:
<pre>
@Entity
class MyClass {
org.joda.time.DateTime foo;
}
</pre>
.. which will result in ugly binary fields in database. Next try:
<pre>
@Entity
class MyClass {
@Type(type = "org.joda.time.contrib.hibernate.PersistentDateTime")
org.joda.time.DateTime foo;
}
</pre>
That works, but now I have to specify that on all time fields of all classes. Plus it's different types for different classes, which makes it more messy. And it's simply a string in code, so it's fragile to refactoring, code move, etc. TypeDefs allow a shorter handle for certain types, but don't really address the refactoring issues.
A better way might be to allow configurations to register UserTypes for known classes. E.g. have a configuration directive like this:
<mappable-type class="org.joda.time.DateTime" usertype="org.joda.time.hibernate.DateTimeType"/>
This would allow the classes to stay clean from type mappings and reduce coupling between domain objects and persistence mapping.
This might be as easy as allowing the org.hibernate.type.TypeFactory map to be extended at configuration time.
--
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, 6 months