April 2011 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-6089) Give detailed example of ManyToMany with same class at both ends and bidirectional....

by Colbert Philippe (JIRA)

Give detailed example of ManyToMany with same class at both ends and bidirectional.... -------------------------------------------------------------------------------------- Key: HHH-6089 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6089 Project: Hibernate Core Issue Type: Task Components: core Affects Versions: 3.6.2 Environment: Windows 7 Reporter: Colbert Philippe I thought I knew Hibernate well but I got stuck with this issue. I am trying to implement a friend relationship between instances of Person class. Naturally, any Person can have any number of friends, which are other instances of Person. The complication comes from the fact that friend relationship is perfectly symmetric and bi-directional in my application. That is if Person(1) is friend with Person(2), then Person(2) is friend with Person(1) also. I want to implement this friend relationship in Hibernate using an intermediate class that will hold certain attributes describing further the friendship relationship like date when friendship started, some text note about the friendship,....etc. Implementing this using Hibernate causes some challenges and even difficulties because I am not sure about how Hibernate handles class IDs internally. Can you provide an example of Hibernate config file that implements the Many-To-Many on the same class at both ends and with intermediate data class? There should be no order in the relationship (i.e. the relationship is perfectly symmetric). I suspect that the solution to this issue is to code a composite id class where there is no order between the two ids from Person class. However, I am not sure whether that is sufficient for Hibernate. -- 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

13 years, 9 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-6087) AuditJoinTable does not default to a concatenation of the primary table names, as stated in Doumentation

by Robin Gersabeck (JIRA)

AuditJoinTable does not default to a concatenation of the primary table names, as stated in Doumentation -------------------------------------------------------------------------------------------------------- Key: HHH-6087 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6087 Project: Hibernate Core Issue Type: Bug Affects Versions: 3.6.2, 3.5.6 Environment: Oracle Reporter: Robin Gersabeck Priority: Minor The Documentation at http://docs.jboss.org/envers/api-new/org/hibernate/envers/AuditJoinTable.... states that the AuditJoinTable "defaults to a concatenation of the names of the primary table of the entity owning the association and of the primary table of the entity referenced by the association." Instead, the default is the concatenation of the two entities' class names. The behavior described in the documentation is preferable to the actual behavior, since it's easy for two concatenated class names to result in an AuditJoinTable name over 30 characters, which Oracle does not support. The relevant part of the code can be found in CollectionMetadataGenerator.java:272 in Hibernate 3.6.2: {quote} return StringTools.getLastComponent(entityName) + "_" + StringTools.getLastComponent(MappingTools.getReferencedEntityName(value.getElement())); {quote} I figured out how to make the second part of the concatenation use the proper table name (but I did not figure out how to also fix the first part yet): {quote} return StringTools.getLastComponent(entityName) + "_" + value.getElement().getTable().getName(); {quote} -- 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

13 years, 9 months

1
0
0 / 0

[Hibernate-JIRA] Created: (ANN-587) @Check doesn't work at property and collection level

by DEBOUTIN Loïc (JIRA)

@Check doesn't work at property and collection level ---------------------------------------------------- Key: ANN-587 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-587 Project: Hibernate Annotations Type: Bug Environment: Hibernate 3.2.2 Hibernate EntityManager:3.2.1.GA Hibernate Annotations :3.2.1.GA Name and version of the database you are using:Oracle XE Serveur d'application : JBoss 4.0.5.GA Reporter: DEBOUTIN Loïc Priority: Minor The @Check annotation doesn't work at property and collection level. it works only at class level. (L'annotation @Check ne fonctionne que lorsqu'elle est définie au niveau de la classe, impossible de définir plusieurs contraintes check pour différents champs d'un même bean). -- 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

13 years, 9 months

5
5
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-724) Fix build assembly - jars in release distribution are misplaced

by Sanne Grinovero (JIRA)

Fix build assembly - jars in release distribution are misplaced --------------------------------------------------------------- Key: HSEARCH-724 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-724 Project: Hibernate Search Issue Type: Task Affects Versions: 3.4.0.CR1 Reporter: Sanne Grinovero Assignee: Sanne Grinovero Priority: Minor Fix For: 3.4.0.CR2 -- 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

13 years, 9 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HHH-6086) Document aoubt the 'Fetch' clause is incorrect.

by Black Dong (JIRA)

Document aoubt the 'Fetch' clause is incorrect. ----------------------------------------------- Key: HHH-6086 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6086 Project: Hibernate Core Issue Type: Bug Components: documentation Affects Versions: 3.6.2 Reporter: Black Dong There is an sentence about the fetch clause, looks like this "Fetch should be used together with setMaxResults() or setFirstResult(),...." Is it correct? According the context, there maybe lost a important word "not", is it right? -- 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

13 years, 9 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-5978) TS: Postgresql 8.x - CustomSQLTest fails because UPPER()'s result is not converted to number.

by Ondrej Zizka (JIRA)

TS: Postgresql 8.x - CustomSQLTest fails because UPPER()'s result is not converted to number. --------------------------------------------------------------------------------------------- Key: HHH-5978 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5978 Project: Hibernate Core Issue Type: Bug Environment: PostgreSQL 8.x JDBC 4 Reporter: Ondrej Zizka Assignee: Strong Liu Fix For: 3.6.2 {quote} create table Role ( id int8 not null, name varchar(255), primary key (id) ) insert into Role (name, id) values ('Patient', upper('1')) /** i did this */ >> ERROR: column "id" is of type bigint but expression is of type text SQLState: 42804 {quote} When inserting pure string, it's ok: {quote} insert into Role (name, id) values ('Patient', upper('1')) /** i did this */ >> 1 Row(s) Inserted {quote} FWICT, this is a PostgreSQL bug. Assigning to Strong Liu for consideration. -- 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

13 years, 9 months

3
7
0 / 0

[Hibernate-JIRA] Created: (HHH-3359) Loader leaks memory when ResultSet wrapping is enabled

by Frans Flippo (JIRA)

Loader leaks memory when ResultSet wrapping is enabled ------------------------------------------------------ Key: HHH-3359 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3359 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.3.0.CR1, 3.2.6 Environment: Hibernate 3.2.6 GA, Oracle 10g database, Oracle JDBC drivers 10.2.0.1.0 for JDK14 Reporter: Frans Flippo Priority: Minor Attachments: ResultSetWrapper.java This issue was already reported on the forums (http://forum.hibernate.org/viewtopic.php?t=968578), but I can find no actual JIRA entry. The issue is that when the hibernate.jdbc.wrap_result_sets property is set to true, ResultSets are never removed from the AbstractBatcher's resultSetsToClose set, eventually causing memory to fill up with ResultSet objects and their associated resources (like PreparedStatements). This issue was witnessed in 3.2.6, but a look at the 3.3 CR1 source code reveals that it's still in there. What happens: 1) org.hibernate.loader.Loader.doQuery calls org.hibernate.loader.Loader.getResultSet 2) org.hibernate.loader.Loader.getResultSet calls Batcher.getResultSet. The AbstractBatcher implementation creates a ResultSet by executing the query and adds it to the AbstractBatcher's resultSetsToClose Set 3) Loader then calls its wrapResultSetIfEnabled method to wraps the ResultSet in a ResultSetWrapper if the wrap_result_sets option is enabled. 4) In Loader.doQuery's finally block, Batcher.closeQueryStatement is called with the PreparedStatement and the *wrapped* ResultSet as parameters 5) closeQueryStatement does: if ( resultSetsToClose.remove( rs ) ) { logCloseResults(); rs.close(); } 6) resultSetsToClose.remove(rs) will always return false if the ResultSet was wrapped, as ResultSetWrapper does not override equals()/hashCode() (and therefore inherits Object's equals() and hashCode()). This means the reference to the original (unwrapped) ResultSet remains (is not removed from the Set) and the ResultSet is not closed either as a result. Workaround: Set hibernate.jdbc.wrap_result_sets to false Solution: implement ResultSetWrapper.equals()/hashCode() (see attached ResultSetWrapper.java) -- 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

13 years, 9 months

4
3
0 / 0

[Hibernate-JIRA] Created: (HHH-6081) Finish up Integrator

by Steve Ebersole (JIRA)

Finish up Integrator -------------------- Key: HHH-6081 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6081 Project: Hibernate Core Issue Type: Task Components: core Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 4.0.0.Alpha2 # Move to o.h.spi package # Utilize java.util.ServiceLoader -- 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

13 years, 9 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HHH-6085) org.hibernate.spi package

by Steve Ebersole (JIRA)

org.hibernate.spi package ------------------------- Key: HHH-6085 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6085 Project: Hibernate Core Issue Type: Task Components: core Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 4.0.0.Alpha2 -- 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

13 years, 9 months

1
2
0 / 0

[Hibernate-JIRA] Commented: (HHH-772) null in maps are handled inconsistently

by Kai Kunstmann (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-772?page=co... ] Kai Kunstmann commented on HHH-772: ----------------------------------- After long thinking about it, I realize now how this "feature request" of allowing null-values in a map is hard to implement reasonably. I'm writing here to help other people understand the problem and maybe introduce another idea for a solution: It is true, that a {{java.util.Map}} is defined in terms of a {{java.util.Set}} of {{java.util.Map.Entry}} with no entry having a key equal to any other entry's key in the same entry-set, and that people want to persist every entry of that set no matter if its missing a value, i.e. they want to persist the _absence of a value_ while not giving up the relation between key and map-owner -- especially with a {{<map-key-many-to-many>}}. There doubtlessly are use-cases for this, and it truly is a reasonable request -- if you look at it from the Java point-of-view. I would like to do that, too, instead of coding complicated workarounds. However, with a simple {{<one-to-many>}} mapping in place of the map-value (even so with a {{<composite-element>}}) it becomes impossible to express the desired _absence of value_, since the key would have to go into the same row as the missing entity (or component), which means having an empty row with nothing in it -- especially no id -- but a key and a reference to the owner to express the _absence of an entity_. This is obviously absurd, and in my opinion the only true reason why this issue _won't fix_. With a {{<one-to-many>}} mapping the value of a map-entry essentially _is_ the entry, which is likewise questionable. A solution to this predicament could be the introduction of an {{<idmap>}} with a surrogate {{<collection-id>}}, which obviously cannot contain a {{<one-to-many>}} mapping but could be made capable of expressing _absence of value_ by the requirement of {{table}} attribute and a {{<many-to-many>}}, {{<many-to-any>}}, {{<element>}} or {{<composite-element>}} mapping as with the {{<idbag>}} to serve as a standalone entry-row with an explicit id. There certainly are other considerations to make -- it's just an idea... > null in maps are handled inconsistently > --------------------------------------- > > Key: HHH-772 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-772 > Project: Hibernate Core > Issue Type: Improvement > Components: core > Reporter: Max Rydahl Andersen > Fix For: 3.1 beta 1 > > > regarding case 00004729. > group.getUsers().put("something", null); > Does not result in any insert. > Inserting "something", null manually into the underlying table and > when hibernate reads the map will have "something"->null in the map. -- 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

13 years, 9 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues April 2011