[Hibernate-JIRA] Resolved: (HHH-1654) Cascade problem when bidir OneToMany overlaps with OneToOne
by Gail Badner (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1654?page=c... ]
Gail Badner resolved HHH-1654.
------------------------------
Resolution: Rejected
Assignee: Gail Badner
> Cascade problem when bidir OneToMany overlaps with OneToOne
> -----------------------------------------------------------
>
> Key: HHH-1654
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1654
> Project: Hibernate Core
> Issue Type: Bug
> Environment: JBoss 4.0.4RC1, any database
> Reporter: Jeff Schnitzer
> Assignee: Gail Badner
> Attachments: ContainerTest6-DenseRelationships.zip
>
>
> Given the following relationships:
> Parent has N children (one-to-many)
> Child has 1 parent (many-to-one, the bidir relationship)
> Parent has 1 "default" child (one-to-one)
> Hibernate is unable to persist this. The code I expect to work:
> Parent p = new Parent();
> p.setChildren(new HashSet<Child>());
>
> Child ch = new Child(p);
> p.getChildren().add(ch);
> p.setDefaultChild(ch);
>
> this.em.persist(p);
> However, it's possible to make it work by relaxing the NOT NULL constraint on the defaultChild relationship and rearranging the order of method calls:
> Parent p = new Parent();
> p.setChildren(new HashSet<Child>());
>
> Child ch = new Child(p);
> p.getChildren().add(ch);
>
> this.em.persist(p);
>
> p.setDefaultChild(ch);
> Of course, Hibernate works fine the one-to-one relationship is eliminated.
> Here is the exception produced by the first code sequence:
> Caused by: org.hibernate.PropertyValueException: not-null property references a null or transient value: test.Child.parent
> at org.hibernate.engine.Nullability.checkNullability(Nullability.java:72)
> at org.hibernate.event.def.AbstractSaveEventListener.performSaveOrReplicate(AbstractSaveEventListener.java:265)
> at org.hibernate.event.def.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:167)
> at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:101)
> at org.hibernate.event.def.DefaultPersistEventListener.entityIsTransient(DefaultPersistEventListener.java:131)
> at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:87)
> at org.hibernate.impl.SessionImpl.firePersist(SessionImpl.java:633)
> at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:625)
> at org.hibernate.engine.CascadingAction$8.cascade(CascadingAction.java:202)
> at org.hibernate.engine.Cascade.cascadeToOne(Cascade.java:213)
> at org.hibernate.engine.Cascade.cascadeAssociation(Cascade.java:157)
> at org.hibernate.engine.Cascade.cascadeProperty(Cascade.java:108)
> at org.hibernate.engine.Cascade.cascade(Cascade.java:248)
> at org.hibernate.event.def.AbstractSaveEventListener.cascadeBeforeSave(AbstractSaveEventListener.java:385)
> at org.hibernate.event.def.AbstractSaveEventListener.performSaveOrReplicate(AbstractSaveEventListener.java:242)
> at org.hibernate.event.def.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:167)
> at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:101)
> at org.hibernate.event.def.DefaultPersistEventListener.entityIsTransient(DefaultPersistEventListener.java:131)
> at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:87)
> at org.hibernate.event.def.DefaultPersistEventListener.onPersist(DefaultPersistEventListener.java:38)
> at org.hibernate.impl.SessionImpl.firePersist(SessionImpl.java:642)
> at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:616)
> at org.hibernate.impl.SessionImpl.persist(SessionImpl.java:620)
> at org.hibernate.ejb.AbstractEntityManagerImpl.persist(AbstractEntityManagerImpl.java:127)
> at org.jboss.ejb3.entity.InjectedEntityManager.persist(InjectedEntityManager.java:141)
> at test.GoBean.go(GoBean.java:30)
> 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.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:109)
> at org.jboss.ejb3.AllowedOperationsInterceptor.invoke(AllowedOperationsInterceptor.java:47)
> at org.jboss.aop.joinpoint.MethodInvocation.invokeNext(MethodInvocation.java:98)
> at org.jboss.aspects.tx.TxPolicy.invokeInOurTx(TxPolicy.java:79)
> ... 41 more
> A test case is attached.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months
[Hibernate-JIRA] Resolved: (HHH-1504) Cascade Broken (worked in 3.0.5)
by Gail Badner (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1504?page=c... ]
Gail Badner resolved HHH-1504.
------------------------------
Resolution: Duplicate
Assignee: Gail Badner
> Cascade Broken (worked in 3.0.5)
> --------------------------------
>
> Key: HHH-1504
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1504
> Project: Hibernate Core
> Issue Type: Bug
> Affects Versions: 3.1.2
> Reporter: Michael Kopp
> Assignee: Gail Badner
> Attachments: Node.hbm.xml, Parameter.hbm.xml, stacktrace.txt, Transition.hbm.xml, Workflow.hbm.xml
>
>
> The attached Mappings worked perfectly in HB 3.0.5, in 3.1 the save throws org.hibernate.PropertyValueException
> org.hibernate.PropertyValueException: not-null property references a null or transient value: com.j2fe.workflow.definition.Transition.target
> I even debugged it and the enity given to org.hibernate.event.def.AbstractSaveEventListener.performSaveOrReplicate (a transition object) contains an object in the 'target'. I have to add that the object in 'target' already contains a generated ID, which means it was already saved. The values array given to the org.hibernate.engine.Nullability.checkNullability does not contain it, which is the cause of the exception, the question is why it was nulled!!
> the Transition bascically contains a 'source' and a 'target' Node. and a Node contains sets of Target Transitions and Source Transitions. This is a network of objects!!
> Please Remember that these mappings worked in 3.0.5, I only have this problem after switching to 3.1.
> I even tried to set cascade to all on every single relation i have in the model and it still produced that error.
> org.hibernate.PropertyValueException: not-null property references a null or transient value: com.j2fe.workflow.definition.Transition.target
> at org.hibernate.engine.Nullability.checkNullability(Nullability.java:72)
> at org.hibernate.event.def.AbstractSaveEventListener.performSaveOrReplicate(AbstractSaveEventListener.java:265)
> at org.hibernate.event.def.AbstractSaveEventListener.performSave(AbstractSaveEventListener.java:167)
> at org.hibernate.event.def.AbstractSaveEventListener.saveWithGeneratedId(AbstractSaveEventListener.java:114)
> at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.saveWithGeneratedOrRequestedId(DefaultSaveOrUpdateEventListener.java:186)
> at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.entityIsTransient(DefaultSaveOrUpdateEventListener.java:175)
> at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.performSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:98)
> at org.hibernate.event.def.DefaultSaveOrUpdateEventListener.onSaveOrUpdate(DefaultSaveOrUpdateEventListener.java:70)
> at org.hibernate.impl.SessionImpl.fireSaveOrUpdate(SessionImpl.java:531)
> at org.hibernate.impl.SessionImpl.saveOrUpdate(SessionImpl.java:523)
> at org.hibernate.engine.CascadingAction$1.cascade(CascadingAction.java:134)
> I will attach the full stacktrace in a file as it is rather big.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 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
14 years, 4 months
[Hibernate-JIRA] Created: (HHH-3102) Cascading ManyToOne collections do not eagerly set identifiers on saveOrUpdate()
by Paul Cowan (JIRA)
Cascading ManyToOne collections do not eagerly set identifiers on saveOrUpdate()
--------------------------------------------------------------------------------
Key: HHH-3102
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3102
Project: Hibernate3
Issue Type: Bug
Components: core
Affects Versions: 3.2.4.sp1
Reporter: Paul Cowan
Priority: Minor
Attachments: HibernateKeyPoolTest.java
Hi all,
Not 100% sure if you'd call this a 'bug' as I'm not sure if the correct behaviour is actually specified anywhere. It's certainly oddly inconsistent though.
Please find attached a standalone test case (requires HSQLDB on the classpath; amend setUp() if you need to use something else) which models a parent-child mapping between 'Mouth' (1) and 'Teeth' (many). The Mouth -> Teeth relationship is bidirectional, with CascadeType.ALL on the single-valued end. Both Mouth and Tooth use a @GenericGenerator, which simply allocates integers from a static keypool.
A mouth with one tooth is created, saveOrUpdate()d, session is flushed, a new tooth is added, mouth is saveOrUpdate()d again, and session is again flushed. The debug output is as follows:
*** After creation
Mouth (id=null) has teeth [canine(id=null)]
*** Save
Mouth (id=1) has teeth [canine(id=2)]
*** Flush
Hibernate: insert into Mouth (id) values (?)
Hibernate: insert into Tooth (mouthId, name, id) values (?, ?, ?)
Mouth (id=1) has teeth [canine(id=2)]
*** Add new
Mouth (id=1) has teeth [canine(id=2), molar(id=null)]
*** Save again
Mouth (id=1) has teeth [canine(id=2), molar(id=null)]
*** Flush again
Hibernate: insert into Tooth (mouthId, name, id) values (?, ?, ?)
Mouth (id=1) has teeth [canine(id=2), molar(id=3)]
As you can see, when initially created the IDs for the mouth and tooth are both null (obviously correct). The saveOrUpdate() on the Mouth object then generates identifier values, even though no DB write has been done yet (the .flush()). So far, so good.
However, when a NEW transient Tooth instance ("molar") is added to the Mouth, and saveOrUpdate() is called once more, the id generator is not invoked, UNTIL such time as the session is flushed.
While I guess it's fine for an object in the 'persistent' state not to actually have an identifier until flush-time (e.g. when using DB-side IDENTITY-type generation), it just seems inconsistent that with a @GenericGenerator the behaviour would vary depending on whether the PARENT object was already persistent or not.
There are some obvious workarounds (e.g. flush the session upon saving, or save the child entity first independently) but I thought I'd clarify if this behaviour is by design or not and suggest that this be made consistent.
--
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
14 years, 4 months
[Hibernate-JIRA] Created: (HSEARCH-980) Byteman dependency is not properly scoped
by Karel Piwko (JIRA)
Byteman dependency is not properly scoped
-----------------------------------------
Key: HSEARCH-980
URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-980
Project: Hibernate Search
Issue Type: Bug
Components: build
Affects Versions: 4.0.0.CR2
Reporter: Karel Piwko
Priority: Critical
The <dependencyManagement> section hibernate-search-parent contains following:
{code}
<dependency>
<groupId>org.jboss.byteman</groupId>
<artifactId>byteman</artifactId>
<version>${bytemanVersion}</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.jboss.byteman</groupId>
<artifactId>byteman-install</artifactId>
<version>${bytemanVersion}</version>
<scope>test</scope>
</dependency>
<dependency>
<groupId>org.jboss.byteman</groupId>
<artifactId>byteman-bmunit</artifactId>
<version>${bytemanVersion}</version>
<scope>test</scope>
</dependency>
{code}
Following modules reference it:
* hibernate-search-orm
* hibernate-search-engine
The former correctly specifies scope to test, the latter however pushed it to compile and therefore byteman becomes a hibernate-search dependency. As byteman is *NOT* synced to Maven Central, this renders project unusable.
Please correct dependency management in your project. There should be no scopes in depedencyManagement section and every module should specify the scope.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months
[Hibernate-JIRA] Created: (HHH-6839) ComponentType has incorrect dirty checking
by Eugene Goroschenya (JIRA)
ComponentType has incorrect dirty checking
------------------------------------------
Key: HHH-6839
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6839
Project: Hibernate Core
Issue Type: Bug
Components: core
Affects Versions: 3.3.1
Reporter: Eugene Goroschenya
Priority: Critical
The problem is that persisted object is always dirty in case when component field was set to component instance with null in all fields even if there were not other changes.
So it leads to unnecessary updating of object.
Formally it changes persisted object but not data in DB and has no sense to mark it dirty and schedule update for such changes in persisted object.
And it even worse in case when Interceptor#onFlushDirty(...) is used to do some additional stuffs and if Envers is used to audit changes.
It seems such problem was foxed for NHibernate, see https://nhibernate.jira.com/browse/NH-901 but not in Hibernate
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months
[Hibernate-JIRA] Created: (HHH-6834) skip test BasicOperationsTest on oracle due to a oracle jdbc driver issue
by Strong Liu (JIRA)
skip test BasicOperationsTest on oracle due to a oracle jdbc driver issue
-------------------------------------------------------------------------
Key: HHH-6834
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6834
Project: Hibernate Core
Issue Type: Bug
Components: testsuite
Reporter: Strong Liu
Assignee: Strong Liu
Priority: Minor
Fix For: 4.0.0.next
{quote}
Hi all,
For a long time, I have been using the Oracle classes12.jar in Tomcat for connection to an Oracle database. I was doing some testing with Oracle AS 10g in prep for a production migration and found an interesting problem. The class type that is returned from the meta data on the ResultSet is not the same type as the actual value using getObject() when dealing with Date fields. I noticed this because I use RowSetDynaClass from Commons BeanUtils. It seems to be a problem with the ojdbc14.jar files because I replaced the drivers in Tomcat and was able to repeat the problem.
Specific example:
create a table with a Date field and populate with information (at least one row).
PreparedStatement stmt = conn.prepareStatement("select * from someTable");
ResultSet rs = stmt.executeQuery();
ResultSetMetaData meta = rs.getMetaData();
try{
int colCount = meta.getColumnCount();
if(rs.next()){
for(int i=1; i<=colCount; i++){
Object v = rs.getObject(i);
String value = "";
if(v != null){
value = v.getClass().getName();
}
else{
value = "Null";
}
System.out.println("Col: "+meta.getColumnName(i)+", meta type: "+meta.getColumnClassName(i)+", actual: "+value);
}
}
} catch(Exception e){
// print error info
}
//output
Col: create_date, meta type: java.sql.Timestamp, actual: java.sql.Date
Has anyone else ran into this? If so, any thoughts on a workaround? I posted a simlar question on the Oracle Technology Network on Thursday and have yet to receive a response. RowSetDynaClass relies on the meta data to convert the actual value, so my only thought right now is to create a ResultSet decorator to "fix" this discrepancy.
{quote}
copied from http://www.experts-exchange.com/Programming/Languages/Java/Q_21511374.html
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
14 years, 4 months