August 2010 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-2989) @Loader using named queries returns null

by Jose Noheda (JIRA)

@Loader using named queries returns null ---------------------------------------- Key: HHH-2989 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2989 Project: Hibernate3 Issue Type: Bug Affects Versions: 3.2.5 Environment: Hibernate 3.2.5, Hibernate Annotations 3.3.0, Hibernate Entity Manager 3.3.1 Reporter: Jose Noheda When using entitymanager.find (class, pk) with a @Loader annotation declared the org.hibernate.persister.entity.NamedQueryLoader load function performs a query.list() call (line 57). This call returns a List of entities and the list is correctly filled with one entry (org.hibernate.impl.SessionImpl line 1121). After returning, the line 62 (of NamedQueryLoader): return session.getPersistenceContext().getEntity( new EntityKey( id, persister, session.getEntityMode() ) ) is unable to find it though. -- 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

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-1976) NamingStrategy.classToTableName receives only class name, not a fully qualified name as stated in javadoc

by Lóránt Pintér (JIRA)

NamingStrategy.classToTableName receives only class name, not a fully qualified name as stated in javadoc --------------------------------------------------------------------------------------------------------- Key: HHH-1976 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1976 Project: Hibernate3 Type: Bug Components: core Versions: 3.1.3, 3.2.0.cr2 Reporter: Lóránt Pintér I have a custom NamingStrategy that overrides classToTableName in EJB3NamingStrategy. Prior to upgrading to Hibernate 3.1.3, my NamingStrategy implementation received the correct classnames as documented in the javadoc at http://www.hibernate.org/hib_docs/v3/api/org/hibernate/cfg/NamingStrategy... Since then, it only receives the name of the class without the package specification. I tried upgrading to 3.2.0.cr2, but it didn't help. -- 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

9
15
0 / 0

[Hibernate-JIRA] Created: (HHH-5428) collection tables are improperly non-quoted when the owning table is quoted

by Emmanuel Bernard (JIRA)

collection tables are improperly non-quoted when the owning table is quoted --------------------------------------------------------------------------- Key: HHH-5428 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5428 Project: Hibernate Core Issue Type: Bug Affects Versions: 3.6.0.Beta1, 3.5.4 Reporter: Emmanuel Bernard Fix For: 3.6.0.Beta2 -- 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

2
18
0 / 0

[Hibernate-JIRA] Created: (HHH-5352) Misleading replacement of commas with cross joins

by Patras Vlad (JIRA)

Misleading replacement of commas with cross joins ------------------------------------------------- Key: HHH-5352 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5352 Project: Hibernate Core Issue Type: Bug Affects Versions: 3.5.3, 3.5.2, 3.5.1, 3.5.0-Final, 3.5.0-CR-2, 3.5.0-CR-1, 3.5.0-Beta-4, 3.5.0-Beta-3, 3.5.0-Beta-2 Environment: Hibernate 3.5.3 Ms SQL Server 2005 Reporter: Patras Vlad There was a new feature implemented in 3.5.0-Beta-2: HHH-1480, as a result, for many dialects, the comma operator "," was replaced with "cross join". As it's already obvious from the feature's description, this changes join precedence. If the query contains outer joins (left or right) this replacement changes the results (because outer join precedence is important). This might not be interpreted as a bug if you know what SQL operator will be generated when you place a comma in HQL, but it's misleading if you don't. A HQL query like: {noformat}select a from A a, B left join B.c c{noformat} is not equivalent with the SQL query: {noformat}select a.* from A.a, B b left join C c on b.cid = c.id{noformat} because the actual SQL query is: {noformat}select a.* from A.a cross join B b left join C c on b.cid = c.id{noformat} The first SQL query would make a left join on B and C and then a cross join with the result and A (and this is what we should expect). The second SQL query makes a cross join on A and B and then a left join with the result and C (this is not expected since we had a comma in HQL). I understand the issues presented in HHH-1480, but they should be expected, i.e. a developer SHOULD expect a faliure from a query like {noformat}select a from A a, B b join a.c C{noformat} because "a" is not visible in the join. Hibernate should not use a cross join behind the scenes to allow such a query at the expense of providing misleading results for others. Maybe turn this into a feature/improvement or add another to allow explicit comma or croos join in HQL, or support parenthesis in HQL. The only workaround I can see for now is to re-order the query like this: {noformat}select a from B left join B.c c, A a{noformat} -- 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
14
0 / 0

[Hibernate-JIRA] Created: (HHH-4073) discriminator formula creates problem in hibernate envers

by Saravana Kumar (JIRA)

discriminator formula creates problem in hibernate envers --------------------------------------------------------- Key: HHH-4073 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4073 Project: Hibernate Core Issue Type: Bug Components: envers Affects Versions: 3.3.x Environment: hibernate-3.3.x, envers-1.2.1.ga-hibernate-3.3.jar (Oracle 10g or HSQLDB) Reporter: Saravana Kumar I map my classes using Single Table per class hierarchy as below @Entity @DiscriminatorFormula ("(select t.c_type from t_type t where t.c_id = c_type)") @Audited public class Attribute...{ ... } or <discriminator type="string"> <formula>(select t.c_type from t_type t where t.c_id = c_type)</formula> </discriminator> When I use envers I get the follwoing error Caused by: java.lang.ClassCastException: org.hibernate.mapping.Formula at org.hibernate.envers.configuration.metadata.MetadataTools.addColumns(MetadataTools.java:154) at org.hibernate.envers.configuration.metadata.AuditMetadataGenerator.generateMappingData(AuditMetadataGenerator.java:263) at org.hibernate.envers.configuration.metadata.AuditMetadataGenerator.generateFirstPass(AuditMetadataGenerator.java:345) at org.hibernate.envers.configuration.EntitiesConfigurator.configure(EntitiesConfigurator.java:87) at org.hibernate.envers.configuration.AuditConfiguration.(AuditConfiguration.java:86) at org.hibernate.envers.configuration.AuditConfiguration.getFor(AuditConfiguration.java:99) at org.hibernate.envers.event.AuditEventListener.initialize(AuditEventListener.java:260) at org.hibernate.event.EventListeners$1.processListener(EventListeners.java:198) at org.hibernate.event.EventListeners.processListeners(EventListeners.java:181) at org.hibernate.event.EventListeners.initializeListeners(EventListeners.java:194) When I tried to debug the problem (AuditMetadataGenerator.java:263) has 260: // Checking if there is a discriminator column 261: if (hasDiscriminator) { 262: Element discriminator_element = class_mapping.addElement("discriminator"); 263: MetadataTools.addColumns(discriminator_element, pc.getDiscriminator().getColumnIterator()); 264: discriminator_element.addAttribute("type", pc.getDiscriminator().getType().getName()); 265: } (MetadataTools.java:154) has 152: public static void addColumns(Element any_mapping, Iterator<Column> columns) { 153: while (columns.hasNext()) { 154: Column column = columns.next(); 155: addColumn(any_mapping, column.getName(), column.getLength(), column.getScale(), column.getPrecision(), 156: column.getSqlType()); 157: } 158: } I see that there is nothing to handle Formula :-( Can you investigate? -- 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

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-2150) There are too many columns in the select statement with the Criteria API

by Slawek Trybus (JIRA)

There are too many columns in the select statement with the Criteria API ------------------------------------------------------------------------ Key: HHH-2150 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2150 Project: Hibernate3 Type: Improvement Components: query-criteria Versions: 3.2.0.ga Environment: Hibernate 3.2.0.cr2 PostgreSQL 8.1.3 Reporter: Slawek Trybus Using Criteria API brings on enclosing all columns from joined tables in generated select statement. It has big efficiency impact on DB especially if there are many joined tables (with many columns each) in a query. There is columns' limitation possible with the Projections API usage, but it makes received objects not fully fledged Hibernate entity objects. It would be good to have posibility to limit amount of columns in select statement to ones connected to entity we are interested in. There is available short discusion about this issue in the forum: http://forum.hibernate.org/viewtopic.php?t=965818 -- 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
2
0 / 0

[Hibernate-JIRA] Created: (HHH-5244) Flesh out H2Dialect temp table support

by Steve Ebersole (JIRA)

Flesh out H2Dialect temp table support -------------------------------------- Key: HHH-5244 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5244 Project: Hibernate Core Issue Type: Improvement Components: core Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 3.6 The main symptom right now is that the test suite runs extremely slow against H2 because the H2Dialect is not properly defining how to work with temp tables. -- 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
6
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: (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-3763) An optional "end revision" column

by Adam Warski (JIRA)

An optional "end revision" column --------------------------------- Key: HHH-3763 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3763 Project: Hibernate Core Issue Type: New Feature Components: envers Reporter: Adam Warski Assignee: Adam Warski The "end revision" column would be optionally generated (basing on a setting), and would contain the number of the revision to which the given data row in an audit table is valid. It would be null if a version is still valid. The column can be calculated basing on the "revision" + id columns, so it will create data redundancy, but it will help speed up queries a lot. -- 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

2
2
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues August 2010