[Hibernate-JIRA] Created: (HHH-1982) Merge doesnt work with composite keys
by Jara Cesnek (JIRA)
Merge doesnt work with composite keys
-------------------------------------
Key: HHH-1982
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1982
Project: Hibernate3
Type: Bug
Components: core
Versions: 3.1.3
Reporter: Jara Cesnek
Merge() operation as defined in JSR220 works fine with our entities with simple keys.
But on tables with composite keys same doesnt works.
Hibernate always try insert into table even when should only update.
@IdClass(DOGaa_smlouva_dodatek.DOGaa_smlouva_dodatekPk.class)
@MappedSuperclass
public abstract class DOGaa_smlouva_dodatek {
@Id
protected Integer id_pripad;
@Id
protected Integer pc_smlouva_dodatek;
@Embeddable
public static class DOGaa_smlouva_dodatekPk implements Serializable {
protected Integer id_pripad;
public Integer getId_pripad() {
return id_pripad;
}
public void setId_pripad(Integer id_pripad) {
this.id_pripad = id_pripad;
}
protected Integer pc_smlouva_dodatek;
public Integer getPc_smlouva_dodatek() {
return pc_smlouva_dodatek;
}
public void setPc_smlouva_dodatek(Integer pc_smlouva_dodatek) {
this.pc_smlouva_dodatek = pc_smlouva_dodatek;
}
public boolean equals(Object other){
if ( !(other instanceof DOGaa_smlouva_dodatekPk) ) {return false;}
DOGaa_smlouva_dodatekPk castOther = (DOGaa_smlouva_dodatekPk) other;
return new EqualsBuilder()
.append(id_pripad,castOther.id_pripad)
.append(pc_smlouva_dodatek,castOther.pc_smlouva_dodatek)
.isEquals();
}
public int hashCode() {
return new HashCodeBuilder()
.append(id_pripad)
.append(pc_smlouva_dodatek)
.toHashCode();
}
}
}
Second thing is when we try delete entity through merge on composite keys:
doAttach = (DOParent) hao.getHibernateTemplate().merge(doDetach);
hao.getHibernateTemplate().delete(doAttach);
hibernate try first insert too and then delete.
When entity has simple key this code work fine.
--
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-2182) Left outer join in hibernate 3.1 Criteria API
by Dinesh Kumar Gupta (JIRA)
Left outer join in hibernate 3.1 Criteria API
---------------------------------------------
Key: HHH-2182
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2182
Project: Hibernate3
Type: Bug
Versions: 3.1
Environment: Running with Spring framework on weblogic server.
Reporter: Dinesh Kumar Gupta
I have required a left outer join implementation in Hibernate criteria API in my project. When I create a alias or a sub croteria by criteria.createCriteria it puts a inner join.
Is there any way to use left outer join in Hibernate 3.1 criteria API if possible then how. My code is like
Session session = getSession();
Criteria crtP = session.createCriteria(NotebookPageImpl.class);
crtP.createCriteria("notes", "a").setFetchMode("notes",FetchMode.EAGER);
crtP.addOrder(Order.asc("title"));
I gets only those results which get matched in both tables. Please solve my problem as soon as possible.......
Thanks in advance.
Dinesh Gupta
--
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-2181) extra join conditions in mapping files
by Matthias Bayer (JIRA)
extra join conditions in mapping files
--------------------------------------
Key: HHH-2181
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2181
Project: Hibernate3
Type: Improvement
Reporter: Matthias Bayer
Allow extra join conditions to be specified in mapping file.
The Criteria API considers this additional join condition.
Benefit is the central declaration.
<hibernate-mapping>
<class name="de.mba.MyClass"
table="MyTable">
<id name="poi" type="string">
<column name="POI" length="22" />
<generator class="assigned" />
</id>
<property name="lupdDatetime" type="timestamp">
<column name="LUPD_DATETIME" length="26" />
</property>
<property name="lupdProcess" type="string">
<column name="LUPD_PROCESS" length="30" />
...
<many-to-one name="assoc1"
class="de.mba.MyAssoc"
insert="false" update="false" not-found="ignore">
<column name="POI" />
//possibility to add extra join condition
???
</many-to-one>
</class>
</hibernate-mapping>
select
*
from
a as a
left outer join b as b
on a.id = b.id
//problem additional join condition
and b.type='XY'
where
...
--
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-1479) Incompatibility of Hibernate 3.1 and JTOpen JDBC drivers for IBM AS/400
by Peter Francq (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1479?page=c... ]
Peter Francq commented on HHH-1479:
-----------------------------------
If your application does not run on different backends then I would suggest to use a sequence generator.
The native generator picks identity, sequence or hilo depending upon the capabilities of the underlying database.
As DB2 on AS400 support sequence I would put somthing like this in my mapping file
<id name="id" type="long" column="person_id">
<generator class="sequence">
<param name="sequence">person_id_sequence</param>
</generator>
</id>
We actually did it to avoid the same problem.
Greetz,
Peter Francq
> Incompatibility of Hibernate 3.1 and JTOpen JDBC drivers for IBM AS/400
> -----------------------------------------------------------------------
>
> Key: HHH-1479
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1479
> Project: Hibernate3
> Type: Patch
> Versions: 3.1
> Environment: Hibernate 3.1
> JDBC driver: JTOpen (for IBM AS/400) http://jt400.sourceforge.net
> Reporter: Davide Rogora
>
>
> Hello,
> I've noticed that from version 3.1 Hibernate, when calling JDBC driver for INSERT statement, uses the following prepareStatement method:
> prepareStatement(String sql, String[] columnNames)
> instead of the following
> prepareStatement(String sql, int autoGeneratedKeys)
> used since versione 3.0.x
> the problem is that JDBC driver for AS/400 (project JTOpen on sourceforge: http://jt400.sourceforge.net) doesn't support the method prepareStatement(String sql, String[] columnNames) so it's not possible to use Hibernate 3.1 with AS/400
> I've also noticed that other open source drivers that support this method (for example MySQL Jdbcconnector or JTDS for Ms-SQLServer) have implemented it using a workaround; infact they call the "old" prepareStatement(String sql, int autoGeneratedKeys) method ignoring the content of the columnNames array.
> Here is the source of the jtds implementation:
> -------------------------------------------------------------------------------
> public PreparedStatement prepareStatement(String sql, String[] columnNames)
> throws SQLException {
> if (columnNames == null) {
> throw new SQLException(
> Messages.get("error.generic.nullparam", "prepareStatement"),"HY092");
> } else if (columnNames.length != 1) {
> throw new SQLException(
> Messages.get("error.generic.needcolname", "prepareStatement"),"HY092");
> }
> return prepareStatement(sql, JtdsStatement.RETURN_GENERATED_KEYS);
> }
> -------------------------------------------------------------------------------
> So I'm asking to the Hibernate team if it's possible to use the old method prepareStatement(String sql, int autoGeneratedKeys) in the future releases of Hibernate.
> Thanks,
> Davide Rogora.
--
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-2179) Criteria query return repeated objects when quering for an object with Lazy one to many association
by Lucas Machado (JIRA)
Criteria query return repeated objects when quering for an object with Lazy one to many association
---------------------------------------------------------------------------------------------------
Key: HHH-2179
URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2179
Project: Hibernate3
Type: Bug
Components: query-criteria
Versions: 3.2.0.cr2
Environment: Windows, HSQLDB, Hibernate Annotations
Reporter: Lucas Machado
Attachments: testVersao.rar
In the above scenario:
ClassA (1) -- (*) ClassB
to implement this we we have the following annotation in ClassA.
@OneToMany( cascade = CascadeType.ALL, fetch=FetchType.EAGER)
public Set<ClassB> getBs(){
....
}
in the database we have 1 row representing ClassA and 3 rows representing ClassB (associated with the unique ClassA)
The problem is:
If we query for
"from ClassA"
returns 1 instance of ClassA as expected
if we repeat the query using Criteria
Criteria crit = session.createCriteria(ClassA.class);
List<ClassA> l = crit.list();
The result is a list with 3 positions filled by the same instance of ClassA.
If we change the FetchType to Lazy the problem is solved
Attached is a sample maven-eclipse project with a test case
--
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: (HB-1014) Hibernate does not remove ID's on a failed flush
by Arnout Engelen (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HB-1014?page=co... ]
Arnout Engelen commented on HB-1014:
------------------------------------
I assume by 'added' you're referring to the hibernate.use_identifer_rollback property (http://www.hibernate.org/hib_docs/v3/reference/en/html/session-configurat...
It didn't appear to work for me, but that might be unrelated.
> Hibernate does not remove ID's on a failed flush
> ------------------------------------------------
>
> Key: HB-1014
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HB-1014
> Project: Hibernate2
> Type: Bug
> Components: core
> Versions: 2.1.4
> Environment: 2.1.4
> PostgreSQL
> Most common in Swing applications
> Reporter: Thomas Meeks
>
>
> A thread about it: http://forum.hibernate.org/viewtopic.php?t=931005
> Conditions to recreate:
> 1. Create a new hibernate session (and transaction, if desired)
> 2. Create a transient object (that hibernate can persist)
> 3. Place the transient object in a known bad state (so that any attempt to persist it will fail)
> 4. Attempt to save the object, which will fail
> 5. Close session, rollback txn
> 6. Fix the error with the object
> 7. Create a new hibernate session/txn
> 8. Attempt to save the object (which will currently fail, though it should not)
> 9. Close session
> The error occurs at step 8. Because hibernate does not set the ID of the object to null, it will assume that the object is in the database. When hibernate attempts to update the object (rather than save), it will fail. This bug is particularily nasty when dealing with cascades, as all objects will be assigned numbers.
> A workaround:
> Have your DAO layer keep track of new objects and manually set the ID to null /after/ the session has closed (if you delete the ID before the session closes, hibernate will complain about the changing of IDs).
> This workaround can get quite messy, however, if one requires the use of cascades.
> A (possible) real fix:
> Have hibernate keep track of all new entities in the session, and upon failure, iterate those entities and set their ID to null.
> Another possibility (enumerated by gavin in the thread mentioned above) is to copy the entire object tree by value, but this could cause real problems in objects with large byte arrays.
> The problem may be difficult to fix, however, I find the fact that the steps outlined above do not work to be very counterintuitive. If not fixed, this bug should be at the very least well documented.
> The exception handling portion of the documentation does not indicate that all newly saved objects must be thrown out if the session they are saved in has an 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] Closed: (HHH-960) Incorectly bound parameters in HQL
by Max Rydahl Andersen (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-960?page=all ]
Max Rydahl Andersen closed HHH-960:
-----------------------------------
Resolution: Duplicate
> Incorectly bound parameters in HQL
> ----------------------------------
>
> Key: HHH-960
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-960
> Project: Hibernate3
> Type: Bug
> Components: core
> Versions: 3.1 beta 2
> Environment: hibernate 3.1 beta 2 and beta3 (presumable other as well)
> Reporter: Misko Hevery
> Attachments: Component.hbm.xml, ComponentProperty.hbm.xml, ComponentValue.hbm.xml, HibernateBug960.zip, junit_testcase_HHH960.patch
>
>
> I have a HQL:
> ==========
> select
> stack.serialNo as stackSN,
> v_p_stack_seal_strips.text as stack_Seal_Strip,
> v_p_size.number as size
> from
> com.sigmaquest.gen.model.Component as stack
> left join stack.containedComponents as cell with cell.componentKind=:kind_cell
> left join stack.values as v_p_stack_seal_strips with v_p_stack_seal_strips.componentProperty=:p_stack_seal_strips
> left join cell.values as v_p_size with v_p_size.componentProperty=:p_size
> where
> stack = :stack
> ==========
> This gets translated to SQL (on oracle)
> ==========
> select
> component0_.serialNo as col_0_0_,
> values2_.val_text as col_1_0_,
> values3_.val_number as col_2_0_
> from
> GEN_COMPONENT component0_
> left outer join GEN_COMPONENT containedc1_ on component0_.ID=containedc1_.containerComponent_id
> and (containedc1_.componentKind_id=?)
> left outer join GEN_COMPONENT_VALUE values3_ on containedc1_.ID=values3_.component_id
> and (values3_.property_id=?)
> left outer join GEN_COMPONENT_VALUE values2_ on component0_.ID=values2_.component_id
> and (values2_.property_id=?)
> where
> component0_.ID=?
> ==========
> The transaltion is correct (with some caviats)
> named bindigs are:
> 1 :kind_cell
> 2 :p_stack_seal_strips
> 2 :size
> 4 :stack
> When these get bound to SQL in the above order the SQL is actualy reversed.
> SQL binding order!
> SQL ?1?: containedc1_ is :kind_cell CORRECT
> SQL ?2?: values3_ is :p_size gets bound to :p_stack_seal_strips WRONG
> SQL ?3?: values3_ is :p_stack_seal_strips gets bound to :p_size WRONG
> SQL ?4?: component0_.ID=? is :stack CORRECT
> Needless to say executing the query produces garabage.
> As far as I can tell the problem is in the way AST transaltes HQL to SQL. It does not always keep the order of the operands as in the above example. I don't understand hibernate codebase sufficiently enough to point you closer to the problem. This bug is a blocker and I am happy to provided any examples/code necesary to reproduce
> -- Misko(a)hevery.com
--
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] Kommentiert: (HHH-960) Incorectly bound parameters in HQL
by Stefan Fleiter (JIRA)
[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-960?page=co... ]
Stefan Fleiter commented on HHH-960:
------------------------------------
The JUnit-Testcase shows the bug is still present in Hibernate 3.2.0 GA.
What can be done to speed up or start investigation of this failure?
It would realy be nice if a Hibernate developer could state his optinion about this!
Thanks a lot in advance.
> Incorectly bound parameters in HQL
> ----------------------------------
>
> Key: HHH-960
> URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-960
> Project: Hibernate3
> Type: Bug
> Components: core
> Versions: 3.1 beta 2
> Environment: hibernate 3.1 beta 2 and beta3 (presumable other as well)
> Reporter: Misko Hevery
> Attachments: Component.hbm.xml, ComponentProperty.hbm.xml, ComponentValue.hbm.xml, HibernateBug960.zip, junit_testcase_HHH960.patch
>
>
> I have a HQL:
> ==========
> select
> stack.serialNo as stackSN,
> v_p_stack_seal_strips.text as stack_Seal_Strip,
> v_p_size.number as size
> from
> com.sigmaquest.gen.model.Component as stack
> left join stack.containedComponents as cell with cell.componentKind=:kind_cell
> left join stack.values as v_p_stack_seal_strips with v_p_stack_seal_strips.componentProperty=:p_stack_seal_strips
> left join cell.values as v_p_size with v_p_size.componentProperty=:p_size
> where
> stack = :stack
> ==========
> This gets translated to SQL (on oracle)
> ==========
> select
> component0_.serialNo as col_0_0_,
> values2_.val_text as col_1_0_,
> values3_.val_number as col_2_0_
> from
> GEN_COMPONENT component0_
> left outer join GEN_COMPONENT containedc1_ on component0_.ID=containedc1_.containerComponent_id
> and (containedc1_.componentKind_id=?)
> left outer join GEN_COMPONENT_VALUE values3_ on containedc1_.ID=values3_.component_id
> and (values3_.property_id=?)
> left outer join GEN_COMPONENT_VALUE values2_ on component0_.ID=values2_.component_id
> and (values2_.property_id=?)
> where
> component0_.ID=?
> ==========
> The transaltion is correct (with some caviats)
> named bindigs are:
> 1 :kind_cell
> 2 :p_stack_seal_strips
> 2 :size
> 4 :stack
> When these get bound to SQL in the above order the SQL is actualy reversed.
> SQL binding order!
> SQL ?1?: containedc1_ is :kind_cell CORRECT
> SQL ?2?: values3_ is :p_size gets bound to :p_stack_seal_strips WRONG
> SQL ?3?: values3_ is :p_stack_seal_strips gets bound to :p_size WRONG
> SQL ?4?: component0_.ID=? is :stack CORRECT
> Needless to say executing the query produces garabage.
> As far as I can tell the problem is in the way AST transaltes HQL to SQL. It does not always keep the order of the operands as in the above example. I don't understand hibernate codebase sufficiently enough to point you closer to the problem. This bug is a blocker and I am happy to provided any examples/code necesary to reproduce
> -- Misko(a)hevery.com
--
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