[Hibernate-JIRA] Closed: (HBX-723) hbm2doc shows abstract classes as tables
by Max Rydahl Andersen (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-723?page=all ]
Max Rydahl Andersen closed HBX-723:
-----------------------------------
Fix Version: 3.2beta8
Resolution: Fixed
fixed - thanks for reporting it.
> hbm2doc shows abstract classes as tables
> ----------------------------------------
>
> Key: HBX-723
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-723
> Project: Hibernate Tools
> Type: Bug
> Components: hbm2doc
> Versions: 3.2beta6
> Environment: Hibernate 3.2 cr3, Oracle database, Windows machine, Ant 1.6..5
> Reporter: Jeff
> Priority: Minor
> Fix For: 3.2beta8
>
>
> Take for example an abstract class Person and a class that extends Person called User. Mapped in one mapping file using <union-subclass>.
> <hibernate-mapping package="crown.core.domainobjects">
> <class name="Person" abstract="true">
> <cache usage="read-write" />
> <id name="id" type="long">
> <column name="PERSON_ID">
> <comment>the primary key for hibernate</comment>
> </column>
> <generator class="sequence">
> <param name="sequence">PERSON_SEQ</param>
> </generator>
> </id>
>
> <property name="firstName" type="string">
> <column name="FIRST_NAME" length="50" not-null="true">
> <comment>the first name</comment>
> </column>
> </property>
> <union-subclass name="User" table="CROWN_USERS" lazy="false">
> <comment>Table of crown users</comment>
> <property name="userName" type="string">
> <column name="USER_NAME" length="15" not-null="true" unique="true">
> <comment>the unique user id</comment>
> </column>
> </property>
> </union-subclass>
> </hibernate-mapping>
> When the hbm2doc ant task is executed it will list the CROWN_USERS table with the columns mapped for both Person and User correctly. However, it will also list a table Person with all the columns mapped in Person even though it isn't actually a table in the database. The <<hbm2ddl> task works correctly and does not create a Person table.
--
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
18 years, 3 months
[Hibernate-JIRA] Commented: (HHH-1569) Immutable Natural Id check fails with ArrayIndexOutOfBounds in some cases
by Jarrod Cuzens (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1569?page=c... ]
Jarrod Cuzens commented on HHH-1569:
------------------------------------
I also had this issue as an ArrayOutOfBoundsException. The patch worked for me as well.
> Immutable Natural Id check fails with ArrayIndexOutOfBounds in some cases
> -------------------------------------------------------------------------
>
> Key: HHH-1569
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1569
> Project: Hibernate3
> Type: Bug
> Components: core
> Versions: 3.1.2
> Environment: Tested with Hibernate 3.1.2, Hsqldb 1.8.0 and Ingres 2.6.0 databases
> Reporter: Tom Dunstan
> Priority: Minor
> Attachments: DefaultFlushEntityEventListener.patch, HibernateTestCase.zip
>
>
> It looks like the fix for HHH-1149 in DefaultFlushEntityEventListener.java exposed another bug. It added the following lines:
> if ( loaded == null ) {
> loaded = session.getPersistenceContext().getNaturalIdSnapshot( identifier, persister );
> }
> Further down, loaded is used thusly:
> int prop = props[i];
> if ( !updateable[prop] ) {
> if ( !types[prop].isEqual( current[prop], loaded[prop], entityMode ) ) {
> throw new HibernateException(
> Problem is, the loaded array passed in has length of the number of all properties for the class, but getNaturalIdSnapshot() returns an array the length of the number of natural key properties on the class. The test case for HHH-1149 happened to work with the fix because the natural key happened to sit at position 0. It's trivial to make it appear somewhere else, and get an ArrayIndexOutOfBoundsException. They're just different arrays.
> I've knocked up a patch against hibernate 3.1.2 which fixes the problem, and also delays loading the snapshot until we actually know that we need to check an immutable property. That saves a database hit per previously unloaded object in cases where all natural keys are mutable.
> Note: I've assumed that the order of the natural key values returned by session.getPersistenceContext().getNaturalIdSnapshot() is the same as the order of the properties returned by persister.getNaturalIdentifierProperties(). If they're not the same, then this won't work, but I don't know what other order would be used.
> (Attaching a modified version of the HHH-1149 test case which causes this to fail, and patch against hibernate 3.1.2).
--
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
18 years, 3 months
[Hibernate-JIRA] Commented: (HHH-879) Enable joining the same association twice with Criteria
by Aleksei Valikov (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-879?page=co... ]
Aleksei Valikov commented on HHH-879:
-------------------------------------
Hi Christian,
I've digged relatively deep in the Criteria API code.
Unfortunatelly there's no simple fix for that.
(sorry for terminology, I'm not a Hibernate developer)
As Gavin said somewhere in the forum, Criteria API comes historically from entity loaders. They solve entity loading tasks quite well BUT they are not exactly the solution for querying. I mean, if Criteria query has a structure that corresponds to the query structure of entity loaders - than it's fine.
When it's not (like duplicate join) then you simply can't make it work. In the case of multiple joins, the API enforces the check of duplicates - and it has very good reasons for that.
So what I understood from my studies, Criteria has a nice API but a wrong architecture.
At the same time HQL does not suffer these constaints at all. Because HQL was intended as querying API from the very start, where Criteria was not.
Like all of you commenters and watchers I also had a task to programmatically create queries. And I've spent several days trying to make Criteria API work on queries a bit more complicated than thos presented in the documentation. After a large number of fruitless efforts I' finally gave up.
My solution was to create an own programmatic API where I could formulate queries in a way similar to Criteria API. Unlike the Criteria API, my queries are finally converted to HQL, not SQL.
Here's an example:
>From record = From.clazz(Record.class, "record");
QueryRule.
from(record).
where(record.property("name").like(Constant.quotedString("%a%"))).
selectDistinct(record.property("id").as("id"));
> Enable joining the same association twice with Criteria
> -------------------------------------------------------
>
> Key: HHH-879
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-879
> Project: Hibernate3
> Type: Improvement
> Components: core
> Reporter: Vladimir Bayanov
>
>
> Make double joining the same association with Criteria.createCriteria possible. See: http://forum.hibernate.org/viewtopic.php?t=931249
--
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
18 years, 3 months
[Hibernate-JIRA] Created: (HHH-2090) Hibernate violates referential integrity of an underlying database
by Andrei Iltchenko (JIRA)
Hibernate violates referential integrity of an underlying database
------------------------------------------------------------------
Key: HHH-2090
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2090
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.0.cr2
Environment: 3.2.CR2
Reporter: Andrei Iltchenko
Priority: Critical
To my surprise I discovered that Hibernate can violate the referential integrity of an underlying relational database when dealing with unidirectional associations. It may leave a foreign key un-nullified when the referred entity is deleted, whereby leading to data corruption.
I used a very simple scenario to discover the problem. Two domain classes ClassA (*) --> ClassB(0..1) each having a single string attribute. The classes are mapped to POJOs:
public class ClassA implements Serializable {
/** Primary key attribute: id. */
private String id;
public String getId() {...}
public void setId(String value) {...}
/** Locking attribute: version. */
private Integer version;
public Integer getVersion() {...}
public void setVersion(Integer value) {...}
/** Regular attribute: nameA. */
private String nameA;
public String getNameA() {...}
public void setNameA(String value) {...}
/** Reference: classB. */
private ClassB classB;
public ClassB getClassB() {...}
public void setClassB(ClassB value) {...}
...
}
public class ClassB implements Serializable {
/** Primary key attribute: id. */
private String id;
public String getId() {...}
public void setId(String value) {...}
/** Locking attribute: version. */
private Integer version;
public Integer getVersion() {...}
public void setVersion(Integer value) {...}
/** Regular attribute: nameB. */
private String nameB;
public String getNameB() {...}
public void setNameB(String value) {...}
}
And the following mapping files are used:
ClassA:
<hibernate-mapping schema="rootpackage">
<class name="ClassA"
table="ClassA" optimistic-lock="version" mutable="true">
<!-- Identifier (primary key) attribute. -->
<id name="id" column="uniqueId" type="string">
<generator class="assigned"/>
</id>
<!-- Locking attribute. -->
<version name="version" column="version_column" type="integer"/>
<!-- Regular attributes. -->
<property name="nameA" type="string">
<column name="nameA"/>
</property>
<!-- Uni-directional many-to-one association to entity: ClassB. -->
<many-to-one name="classB" class="ClassB" cascade="all">
<column name="ClassBUniqueId"/>
</many-to-one>
</class>
</hibernate-mapping>
ClassB:
<hibernate-mapping schema="rootpackage">
<class
name="ClassB"
table="ClassB" optimistic-lock="version" mutable="true">
<!-- Identifier (primary key) attribute. -->
<id name="id" column="uniqueId" type="string">
<generator class="assigned"/>
</id>
<!-- Locking attribute. -->
<version name="version" column="version_column" type="integer"/>
<!-- Regular attributes. -->
<property name="nameB" type="string">
<column name="nameB"/>
</property>
</class>
</hibernate-mapping>
If I create one ClassA POJO instance associated with a ClassB POJO and persist the changes, I get the following in my database tables:
ClassA
CLASSBUNIQUEID VERSION_COLUMN UNIQUEID NAMEA
1 0 1 name1a
ClassB
VERSION_COLUMN UNIQUEID NAMEB
0 1 name1b
If I then start a new Session, get the ClassB POJO:
pojo = (ClassB) session.get(ClassB.class, "1");
and delete it:
session.delete(pojo);
tx.commit();
session.close();
I see that the ClassB record has correctly been removed from the table, but the corresponding ClassA record still hold the foreign key to the non-existent ClassB entity.
ClassA
CLASSBUNIQUEID VERSION_COLUMN UNIQUEID NAMEA
1 0 1 name1a
Yes, a ClassB POJO has no reference to a ClassA POJO and Hibernate uses transitive persistence, but Hibernate has all necessary information in the mapping files to see that when deleting a ClassB entity, the other end's FK must be nullified. It must ensure that database data corruption never occurs as a result of its operation. The only "remedy" I discovered against the problem is the not-found="ignore" attribute of the many-to-one element. But this is merely trying to sweep the problem under the carpet rather than dealing with it.
I am genuinely surprised at Hibernate not being able to correctly and transparently handle unidirectional associations in this version of the product (3.2). This is something that most primitive of EJB CMP engines got correctly in early versions of their products.
--
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
18 years, 3 months
[Hibernate-JIRA] Created: (HHH-2087) lazy="extra" on Set's is broken - operationQueue is not considered when accessing set
by Max Rydahl Andersen (JIRA)
lazy="extra" on Set's is broken - operationQueue is not considered when accessing set
-------------------------------------------------------------------------------------
Key: HHH-2087
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2087
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.0.cr4
Reporter: Max Rydahl Andersen
Priority: Critical
adding to a loaded list is not reflected in the .size() method (and addAll() is possibly also affected)
I created ExtraLazyTest.testExtraLazySet in the test suite that shows the issue.
User person = (User) s.get(User.class, gavin.getName());
new Document( "Fresh", "word", person );
System.out.println("Writing out the persons documentes (Set). Expected to find 3 but it only contains 2.");
for (Iterator iter = person.getDocuments().iterator(); iter.hasNext();) { // changes should be written at this time...
Document doc = (Document) iter.next();
System.out.println("phoneNumber: " + doc);
}
assertTrue(person.getDocuments().size() == 3);
Changing PeristentSet.endRead() to:
public boolean endRead() {
set.addAll(tempList);
tempList = null;
return afterInitialize(); // ensures that operationQueue is considered.
}
makes it work.
--
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
18 years, 3 months
[Hibernate-JIRA] Commenté: (HHH-944) In one-to-many relationship (Set, Map, List), let <key> accept <formula> as an alternative to <column>.
by Xavier Brénuchon (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-944?page=co... ]
Xavier Brénuchon commented on HHH-944:
--------------------------------------
I posted a patch for use <formula> in <key> for <one-to-many> : HHH-2086
Even if it is simple, this patch relates to more class that I thought.
> In one-to-many relationship (Set, Map, List), let <key> accept <formula> as an alternative to <column>.
> ---------------------------------------------------------------------------------------------------------
>
> Key: HHH-944
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-944
> Project: Hibernate3
> Type: New Feature
> Versions: 3.1 rc3
> Reporter: Etienne Laverdiere
>
>
> As explain in http://forum.hibernate.org/viewtopic.php?t=947249&highlight=&sid=c6df51fc... and alternatively in http://forum.hibernate.org/viewtopic.php?t=947145&highlight=&sid=c6df51fc..., it would be nice if the <key> inside a SET or any collection (one-to-many relationship) could accept a <formula> instead of the column:
> Example:
> <set name="childrens" lazy="true" inverse="true">
> <key foreign-key="FinancialTransit">
> <formula>ANY SQL</formula>
> </key>
> <one-to-many class="com.eg.Children" />
> </set>
> instead of :
> <set name="childrens" lazy="true" inverse="true">
> <key foreign-key="key1">
> <column name="key2" scale="10"
> precision="0" not-null="false" unique="true" />
> </key>
> <one-to-many class="com.eg.Children" />
> </set>
> It would necessitate to patch the class AbstractCollectionPersister and modify the DTD of hibernate mapping.
> Regards,
> Etienne
--
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
18 years, 3 months
[Hibernate-JIRA] Créée: (HHH-2076) Bidirectionnal many-to-one with formula and one-to-one doesn't work
by Xavier Brénuchon (JIRA)
Bidirectionnal many-to-one with formula and one-to-one doesn't work
--------------------------------------------------------------------
Key: HHH-2076
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2076
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.2.0.cr4
Reporter: Xavier Brénuchon
Attachments: onetoone_bidirectionnal_formula.zip
Hello,
There is a bug with one-to-one association with foreign key associations (doc 5.1.11).
I use composite-id and a formula in many-to-one :
<class name="Person">
<composite-id>
<key-property name="company" type="string" column="COMPANY"/>
<key-property name="name" type="string" column="NAME"/>
</composite-id>
<property name="age" type="int" column="AGE"/>
<many-to-one name="car" class="Car" unique="true">
<formula>company</formula>
<column name="FK_CAR_REGISTRATION"/>
</many-to-one>
</class>
<class name="Car">
<composite-id>
<key-property name="company" type="string" column="COMPANY"/>
<key-property name="registration" type="string" column="REGISTRATION"/>
</composite-id>
<property name="color" type="string" column="COLOR"/>
<one-to-one name="person" class="Person" property-ref="car"/>
</class>
I have a problem because Hibernate can't use a formula in the right part of outer join :
DEBUG SQL:393 -
select
this_.COMPANY as COMPANY1_1_,
this_.REGISTRATION as REGISTRA2_1_1_,
this_.COLOR as COLOR1_1_,
person2_.COMPANY as COMPANY0_0_,
person2_.NAME as NAME0_0_,
person2_.AGE as AGE0_0_,
person2_.FK_CAR_REGISTRATION as FK4_0_0_,
person2_.company as formula0_0_
from
Car this_
left outer join
Person person2_
on this_.COMPANY=person2_.null
and this_.REGISTRATION=person2_.FK_CAR_REGISTRATION
DEBUG AbstractBatcher:476 - preparing statement
DEBUG JDBCExceptionReporter:63 - could not execute query [select this_.COMPANY as COMPANY1_1_, this_.REGISTRATION as REGISTRA2_1_1_, this_.COLOR as COLOR1_1_, person2_.COMPANY as COMPANY0_0_, person2_.NAME as NAME0_0_, person2_.AGE as AGE0_0_, person2_.FK_CAR_REGISTRATION as FK4_0_0_, person2_.company as formula0_0_ from Car this_ left outer join Person person2_ on this_.COMPANY=person2_.null and this_.REGISTRATION=person2_.FK_CAR_REGISTRATION]
java.sql.SQLException: Column not found: NULL in statement [select this_.COMPANY as COMPANY1_1_, this_.REGISTRATION as REGISTRA2_1_1_, this_.COLOR as COLOR1_1_, person2_.COMPANY as COMPANY0_0_, person2_.NAME as NAME0_0_, person2_.AGE as AGE0_0_, person2_.FK_CAR_REGISTRATION as FK4_0_0_, person2_.company as formula0_0_ from Car this_ left outer join Person person2_ on this_.COMPANY=person2_.null and this_.REGISTRATION=person2_.FK_CAR_REGISTRATION]
at org.hsqldb.jdbc.Util.throwError(Unknown Source)
at org.hsqldb.jdbc.jdbcPreparedStatement.<init>(Unknown Source)
at org.hsqldb.jdbc.jdbcConnection.prepareStatement(Unknown Source)
at org.hibernate.jdbc.AbstractBatcher.getPreparedStatement(AbstractBatcher.java:497)
at org.hibernate.jdbc.AbstractBatcher.getPreparedStatement(AbstractBatcher.java:415)
at org.hibernate.jdbc.AbstractBatcher.prepareQueryStatement(AbstractBatcher.java:139)
at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1561)
at org.hibernate.loader.Loader.doQuery(Loader.java:661)
at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:224)
at org.hibernate.loader.Loader.doList(Loader.java:2144)
at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2028)
at org.hibernate.loader.Loader.list(Loader.java:2023)
at org.hibernate.loader.criteria.CriteriaLoader.list(CriteriaLoader.java:95)
at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1569)
at org.hibernate.impl.CriteriaImpl.list(CriteriaImpl.java:283)
at org.hibernate.impl.CriteriaImpl.uniqueResult(CriteriaImpl.java:305)
at org.hibernate.test.onetoone.bidirectionnalformula.OneToOneBidirectionalFormulaTest.testReadOneToOneBidirectionalFormula(OneToOneBidirectionalFormulaTest.java:47)
In fact this problem is linked with HHH-944. Soon, I will send a patch which corrects this bug and makes an evolution for HHH-944.
Testcase in onetoone_bidirectionnal_formula.zip :org.hibernate.test.onetoone.bidirectionnalformula.OneToOneBidirectionalFormulaTest
--
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
18 years, 3 months