[Hibernate-JIRA] Created: (HBX-779) jdbc reengineer sql-type problem with oracle 9i
by jacky hua (JIRA)
jdbc reengineer sql-type problem with oracle 9i
-----------------------------------------------
Key: HBX-779
URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-779
Project: Hibernate Tools
Type: Bug
Components: reverse-engineer
Versions: 3.2beta8
Environment: windowsxp sp2, jdk 1.4.2, eclipse 3.1.2
Reporter: jacky hua
I used the ant task hibernate-tools provided like the below to generate hbms xml
<target name="default" description="generate hbm">
<delete dir="./generate"/>
<mkdir dir="./generate"/>
<hibernatetool destdir="./generate">
<jdbcconfiguration
configurationfile="./metadata/hibernate.cfg.xml"
revengfile="./metadata/hibernate.reveng.xml"
packagename="net.ema.examples.sa"
detectmanytomany="true"
detectoptimisticlock="true">
</jdbcconfiguration>
<hbm2hbmxml destdir="./generate" />
</hibernatetool>
</target>
the ./metadata/hibernate.cfg.xml like the below:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE hibernate-reverse-engineering
SYSTEM "http://hibernate.sourceforge.net/hibernate-reverse-engineering-3.0.dtd" >
<hibernate-reverse-engineering>
<schema-selection match-catalog="TITAN" match-schema="TITAN" />
<type-mapping>
<!-- jdbc-type is name fom java.sql.Types -->
<!-- length, scale and precision can be used to specify the mapping precisly -->
<sql-type jdbc-type="NUMERIC" precision="1"
hibernate-type="boolean" />
<!-- the type-mappings are ordered. This mapping will be consulted last,
thus overriden by the previous one if precision=1 for the column -->
<sql-type jdbc-type="NUMERIC" precision="19" hibernate-type="long" />
<sql-type jdbc-type="TIMESTAMP" hibernate-type="java.util.Date" />
</type-mapping>
<!-- BIN$ is recycle bin tables in Oracle -->
<table-filter match-name="BIN$.*" exclude="true" />
</hibernate-reverse-engineering>
But the <sql-type jdbc-type="NUMERIC" precision="19" hibernate-type="long" /> didn't work, also generate big_decimal type not long type, otherwise the others two sql-type rules worked. the not affected column:USER_ID was pk of my table. the generated hbm file is like the below:
<class name="net.ema.examples.sa.UserModel" table="T_SA_USER" schema="TITAN">
<id name="userId" type="big_decimal">
<column name="USER_ID" scale="0" />
<generator class="assigned" />
</id>
<property name="logonName" type="string">
<column name="LOGON_NAME" length="60" />
</property>
<property name="password" type="string">
<column name="PASSWORD" length="80" />
</property>
<property name="isOrgAdmin" type="java.lang.Boolean">
<column name="IS_ORG_ADMIN" precision="1" scale="0" />
</property>
<property name="remark" type="string">
<column name="REMARK" length="400" />
</property>
<property name="createDate" type="java.util.Date">
<column name="CREATE_DATE" length="11" />
</property>
<property name="status" type="string">
<column name="STATUS" length="2" />
</property>
</class>
--
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, 10 months
[Hibernate-JIRA] Created: (HHH-2782) Component getType caches the type value
by Kiss Zoltán (JIRA)
Component getType caches the type value
---------------------------------------
Key: HHH-2782
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2782
Project: Hibernate3
Issue Type: Bug
Affects Versions: 3.2.5
Environment: all
Reporter: Kiss Zoltán
Component class caches the value of the type attribute:
public Type getType() throws MappingException {
// added this caching as I noticed that getType() is being called multiple times...
if ( type == null ) {
type = buildType();
}
return type;
}
This forbids the use of 'dynamic attributes'.
For eg. if you try to add new properties to an existing dynamic-component with the addProperty method, then the rebuild of the session factory will failed, because the Component property will be invalid during the validation (in the Component there will be a different column span value, then in the cached ComponentType).
There should be a method like this in the Component class:
public void rebuildType() {
type = buildType();
}
With the help of this the type could be rebuild if it is necessary.
--
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, 11 months
[Hibernate-JIRA] Created: (HHH-2124) HibernateException hidden during flush using XA with WAS6
by Ole Dalgaard (JIRA)
HibernateException hidden during flush using XA with WAS6
---------------------------------------------------------
Key: HHH-2124
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2124
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.1.2, 3.1.3
Environment: Hibernate 3.1.3
Oracle 10G
Websphere Application Server 6
Reporter: Ole Dalgaard
In an XA environment, using WebSphereExtendedJTATransactionLookup, HibernateExceptions are hidden during flush in this code in CacheSynchronization.java
try {
if (flush) {
log.trace("automatically flushing session");
ctx.managedFlush();
}
}
catch (RuntimeException re) {
setRollbackOnly();
throw re;
}
After adding some logging to CacheSynchronization.beforeCompletion I got this error message:
org.hibernate.HibernateException: Illegal attempt to associate a collection with two open sessions
at org.hibernate.collection.AbstractPersistentCollection.setCurrentSession(AbstractPersistentCollection.java:410)
at org.hibernate.event.def.OnUpdateVisitor.processCollection(OnUpdateVisitor.java:40)
at org.hibernate.event.def.AbstractVisitor.processValue(AbstractVisitor.java(Compiled Code))
at org.hibernate.event.def.AbstractVisitor.processValue(AbstractVisitor.java(Compiled Code))
at org.hibernate.event.def.AbstractVisitor.processEntityPropertyValues(AbstractVisitor.java(Compiled Code))
at org.hibernate.event.def.AbstractVisitor.process(AbstractVisitor.java:123)
at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.performUpdate(DefaultSaveOrUpdateEventListener.java:267)
at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.entityIsDetached(DefaultSaveOrUpdateEventListener.java:216)
at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.performSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:93)
at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.onSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:70)
at org.hibernate.impl.SessionImpl.fireSaveOrUpdate(SessionImpl.java:502)
at org.hibernate.impl.SessionImpl.saveOrUpdate(SessionImpl.java:494)
at org.hibernate.engine.CascadingAction$5.cascade(CascadingAction.java:134)
at org.hibernate.engine.Cascade.cascadeToOne(Cascade.java(Inlined Compiled Code))
at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java(Compiled Code))
at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java(Compiled Code))
at org.hibernate.engine.Cascade.cascade(Cascade.java(Compiled Code))
at org.hibernate.event.def.AbstractFlushingEventListener.cascadeOnFlush(AbstractFlushingEventListener.java:130)
at org.hibernate.event.def.AbstractFlushingEventListener.prepareEntityFlushes(AbstractFlushingEventListener.java:121)
at org.hibernate.event.def.AbstractFlushingEventListener.flushEverythingToExecutions(AbstractFlushingEventListener.java:65)
at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:26)
at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:985)
at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:333)
at org.hibernate.transaction.CacheSynchronization.beforeCompletion(CacheSynchronization.java:60)
at org.hibernate.transaction.WebSphereExtendedJTATransactionLookup$TransactionManagerAdapter$TransactionAdapter$1.invoke(WebSphereExtendedJTATransactionLookup.java:136)
at $Proxy11.beforeCompletion(Unknown Source)
at com.ibm.ws.jtaextensions.SynchronizationCallbackWrapper.beforeCompletion(SynchronizationCallbackWrapper.java:65)
at com.ibm.ws.Transaction.JTA.RegisteredSyncs.distributeBefore(RegisteredSyncs.java(Compiled Code))
at com.ibm.ws.Transaction.JTA.TransactionImpl.prePrepare(TransactionImpl.java(Compiled Code))
at com.ibm.ws.Transaction.JTA.TransactionImpl.stage1CommitProcessing(TransactionImpl.java(Compiled Code))
at com.ibm.ws.Transaction.JTA.TransactionImpl.processCommit(TransactionImpl.java(Compiled Code))
at com.ibm.ws.Transaction.JTA.TransactionImpl.commit(TransactionImpl.java(Compiled Code))
at com.ibm.ws.Transaction.JTA.TranManagerImpl.commit(TranManagerImpl.java(Compiled Code))
at com.ibm.ws.Transaction.JTA.TranManagerSet.commit(TranManagerSet.java(Compiled Code))
at com.ibm.ejs.csi.TranStrategy.commit(TranStrategy.java:716)
at com.ibm.ejs.csi.TranStrategy.postInvoke(TranStrategy.java:167)
at com.ibm.ejs.csi.TransactionControlImpl.postInvoke(TransactionControlImpl.java:569)
at com.ibm.ejs.container.EJSContainer.postInvoke(EJSContainer.java:3801)
at com.ibm.ws.webservices.dispatchers.ejb.WSEJBWrapper.postInvoke(WSEJBWrapper.java:153)
at com.ibm.ws.webservices.dispatchers.ejb.J2ee14EJBDispatcher.cleanupEnvironment(J2ee14EJBDispatcher.java:197)
at com.ibm.ws.webservices.engine.handlers.jaxrpc.JAXRPCHandler.invoke(JAXRPCHandler.java:148)
at com.ibm.ws.webservices.engine.handlers.WrappedHandler.invoke(WrappedHandler.java:64)
at com.ibm.ws.webservices.engine.PivotHandlerWrapper.invoke(PivotHandlerWrapper.java:225)
at com.ibm.ws.webservices.engine.PivotHandlerWrapper.invoke(PivotHandlerWrapper.java:225)
at com.ibm.ws.webservices.engine.WebServicesEngine.invoke(WebServicesEngine.java:279)
at com.ibm.ws.webservices.engine.transport.http.WebServicesServlet.doPost(WebServicesServlet.java:717)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:763)
at com.ibm.ws.webservices.engine.transport.http.WebServicesServletBase.service(WebServicesServletBase.java:341)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:856)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.service(ServletWrapper.java:1282)
at com.ibm.ws.webcontainer.servlet.ServletWrapper.handleRequest(ServletWrapper.java:673)
at com.ibm.ws.webcontainer.servlet.CacheServletWrapper.handleRequest(CacheServletWrapper.java:80)
at com.ibm.ws.webcontainer.WebContainer.handleRequest(WebContainer.java:1804)
at com.ibm.ws.webcontainer.channel.WCChannelLink.ready(WCChannelLink.java:84)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleDiscrimination(HttpInboundLink.java:469)
at com.ibm.ws.http.channel.inbound.impl.HttpInboundLink.handleNewInformation(HttpInboundLink.java:408)
at com.ibm.ws.http.channel.inbound.impl.HttpICLReadCallback.complete(HttpICLReadCallback.java:101)
at com.ibm.ws.tcp.channel.impl.WorkQueueManager.requestComplete(WorkQueueManager.java:566)
at com.ibm.ws.tcp.channel.impl.WorkQueueManager.attemptIO(WorkQueueManager.java:619)
at com.ibm.ws.tcp.channel.impl.WorkQueueManager.workerRun(WorkQueueManager.java:952)
at com.ibm.ws.tcp.channel.impl.WorkQueueManager$Worker.run(WorkQueueManager.java:1039)
at com.ibm.ws.util.ThreadPool$Worker.run(ThreadPool.java(Compiled Code))
Without modifying CacheSynchronization I only get this:
WTRN0074E: Exception caught from before_completion synchronization operation: java.lang.UnsupportedOperationException
at org.hibernate.transaction.WebSphereExtendedJTATransactionLookup$TransactionManagerAdapter$TransactionAdapter.setRollbackOnly(WebSphereExtendedJTATransactionLookup.java:211)
at org.hibernate.transaction.CacheSynchronization.setRollbackOnly(CacheSynchronization.java:77)
at org.hibernate.transaction.CacheSynchronization.beforeCompletion(CacheSynchronization.java:67)
at org.hibernate.transaction.WebSphereExtendedJTATransactionLookup$TransactionManagerAdapter$TransactionAdapter$1.invoke(WebSphereExtendedJTATransactionLookup.java:136)
at $Proxy11.beforeCompletion(Unknown Source)
at com.ibm.ws.jtaextensions.SynchronizationCallbackWrapper.beforeCompletion(SynchronizationCallbackWrapper.java:65)
at com.ibm.ws.Transaction.JTA.RegisteredSyncs.distributeBefore(RegisteredSyncs.java(Compiled Code))
at com.ibm.ws.Transaction.JTA.TransactionImpl.prePrepare(TransactionImpl.java(Compiled Code))
.....
I use these transaction settings for hibernate:
<property name="hibernate.transaction.factory_class">org.hibernate.transaction.JTATransactionFactory</property>
<property name="hibernate.transaction.manager_lookup_class">org.hibernate.transaction.WebSphereExtendedJTATransactionLookup</property>
<property name="hibernate.transaction.flush_before_completion">true</property>
<property name="hibernate.transaction.auto_close_session">true</property>
--
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, 11 months
[Hibernate-JIRA] Created: (HHH-2599) Inconsistent behaviour with Cascade Refresh and lazy loaded collections
by Guy Chua (JIRA)
Inconsistent behaviour with Cascade Refresh and lazy loaded collections
-----------------------------------------------------------------------
Key: HHH-2599
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2599
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.3
Environment: 3.2.3, hsqldb/mysql
Reporter: Guy Chua
Attachments: cascadeTest.zip
According to the specs for session.refresh(), the state of the given instance will be re-read from the database. I have a model 'Company' that has 2 lazy collections, departments and employees.
Snippet of class Company
--------------------------------------------------------------------
@OneToMany (mappedBy="company", cascade={ CascadeType.ALL }) // POINT 1
private Set<Department> departments; // POINT 1
@OneToMany (mappedBy="company", cascade={ CascadeType.ALL }) // POINT 2
private Set<Employee> employees; // POINT 2
Snippet of class CascadeTestRunner
--------------------------------------------------------------------
public void doRefreshTest() {
session = sessionFactory.openSession();
session.getTransaction().begin();
Company loadedCompany = (Company)session.get(Company.class, companyId);
logger.debug(loadedCompany);
// session.refresh(loadedCompany); // POINT A
session.close();
Set<Department> loadedDepartments = loadedCompany.getDepartments();
logger.debug("TEST for LAZY DEPARTMENTS [START]");
for (Department tmpDepartment : loadedDepartments) {
logger.debug(tmpDepartment); // POINT B
}
logger.debug("TEST for LAZY DEPARTMENTS [END]");
Set<Employee> loadedEmployees = loadedCompany.getEmployees();
logger.debug("TEST for LAZY EMPLOYEES [START]");
for (Employee tmpEmployee : loadedEmployees) {
logger.debug(tmpEmployee); // POINT C
}
logger.debug("TEST for LAZY EMPLOYEES [END]");
}
If I run the above code, Point B will give me LazyInitializationException which is the expected behavior. But if i uncomment POINT A, the LazyInitializationException happens at POINT C instead of POINT B. Why should POINT B pass and POINT C fail?
Furthermore, with POINT A still uncommented and when I swap the position of POINT 1 with POINT 2, the LazyInitializationException happens at POINT B now. I am wondering why the position of the fields produce the exception at a different location.
What happens when a lazy collection annotated with CascadeType.Refresh is refreshed? I am getting varied results, sometimes the collection is initialized, sometimes it is not. Is it supposed to cascade the refresh to lazy elements in the first place?
Hope someone can shed some light on this.
Test Results
------------------
1. LazyInitializationException at POINT B
@OneToMany (mappedBy="company", cascade={ CascadeType.ALL }) // POINT 1
private Set<Department> departments; // POINT 1
@OneToMany (mappedBy="company", cascade={ CascadeType.ALL }) // POINT 2
private Set<Employee> employees; // POINT 2
// session.refresh(loadedCompany); // POINT A
logger.debug(tmpDepartment); // POINT B
logger.debug(tmpEmployee); // POINT C
2. LazyInitializationException at POINT C
@OneToMany (mappedBy="company", cascade={ CascadeType.ALL }) // POINT 1
private Set<Department> departments; // POINT 1
@OneToMany (mappedBy="company", cascade={ CascadeType.ALL }) // POINT 2
private Set<Employee> employees; // POINT 2
session.refresh(loadedCompany); // POINT A
logger.debug(tmpDepartment); // POINT B
logger.debug(tmpEmployee); // POINT C
2. LazyInitializationException at POINT B when positions of POINT 1 and POINT 2 are swapped
@OneToMany (mappedBy="company", cascade={ CascadeType.ALL }) // POINT 2
private Set<Employee> employees; // POINT 2
@OneToMany (mappedBy="company", cascade={ CascadeType.ALL }) // POINT 1
private Set<Department> departments; // POINT 1
session.refresh(loadedCompany); // POINT A
logger.debug(tmpDepartment); // POINT B
logger.debug(tmpEmployee); // POINT C
--
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, 11 months
[Hibernate-JIRA] Créée: (HHH-2060) To be able to use <generator> with <composite-id>
by Xavier Brénuchon (JIRA)
To be able to use <generator> with <composite-id>
-------------------------------------------------
Key: HHH-2060
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2060
Project: Hibernate3
Type: Improvement
Versions: 3.2.0.cr4
Environment: Hibernate 3.x
Reporter: Xavier Brénuchon
Hello,
This is the continuation of HB-389
We develop an application which has very strong need for performance with several tens of million recordings. Partitioning is a need.
So for that, I use <composite-id>. But my primary key is not a natural key, but a real technical key :
- column of partitioning for optimization of the data base
- column of technical id
So I need to have a generator, for exemple :
<composite-id name="id" class="IdPartition">
<key-property name="org" type="string" column="ORG"/>
<key-property name="id" type="long" column="ID"/>
<generator class="fr.test.xavier.IdPartitionGenerator">
<param name="table">TAB_SEQ</param>
<param name="column">LAST</param>
</generator>
</composite-id>
The good news is that Hibernate can use that (HB-389).
In fact, it is enough to modify the DTD to authorize <generator> in <composite-id> and it is all. The current code of Hibernate manages it very well.
Is it possible that Hibernate is enriched by this functionality?
--
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, 11 months