March 2009 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-2544) Create the EntityPersisters in order based on Inheritance hierarchy

by Shawn Clowater (JIRA)

Create the EntityPersisters in order based on Inheritance hierarchy ------------------------------------------------------------------- Key: HHH-2544 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2544 Project: Hibernate3 Issue Type: New Feature Components: core Affects Versions: 3.2.3 Reporter: Shawn Clowater Priority: Minor I have a bit of what might seem to be an odd request. I had run into a scenario where filters on my mappings that were part of a Single Table hierarchy were not getting into the configuration and it turned out it was based on the order that the EntityPersisters were being created as we've doing some minor magic with Custom EntityPersisters for filters. In our case we have a filter template where the filter is pretty much the same for each class that implements it except for the table and key name used in the filter. So, rather than define this annotation everywhere (we had previously been using xdoclet to generate it for the hbm mappings) we pushed the logic into a Custom Persister. So, essentially as it is building the EntityPersister we intercept the PersistentClass before it calls the super() constructor and add our required filters on the PersistantClass (in its FilterMap) before it gets passed up. This is done like this because by the time it gets to the AbstractEntityPersister's constructor it uses the filterMap to construct the FilterHelper and then you're done as you have no access to change that after it is built. So, in the Inheritance case any subclasses that are built before the main root class will not have the filters that we inject during the construction of our Custom Entity Persisters. I have temporarily worked around it by changing the Subclasses getFilterMap() method to not only return the filters from the Parent class but also from the class itself. Now, normally you can't define the filter on the subclass but I can through the persister. What I'd like to do is: Make the persister class for the subclasses a 'standard' persister that doesn't add any filters to the subclass. Still have my root class' entity persister adding the filters. But have the Entity Persisters built in hierarchal order in the SessionFactoryImpl. Since they are being built in any given order right now, I can't see an issue with providing some order to them, something like the AnnotationBinder does. -- 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, 11 months

1
2
0 / 0

[Hibernate-JIRA] Created: (HHH-2579) scope bytecode provider selection to session factory

by Steve Ebersole (JIRA)

scope bytecode provider selection to session factory ---------------------------------------------------- Key: HHH-2579 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2579 Project: Hibernate3 Issue Type: Improvement Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: cfg-rework currently this is one of those "static" config params (classloader wide). -- 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, 11 months

1
5
0 / 0

[Hibernate-JIRA] Created: (HHH-3574) ANY mapping ignores lazy="false"

by Manuel Dominguez Sarmiento (JIRA)

ANY mapping ignores lazy="false" -------------------------------- Key: HHH-3574 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3574 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.1 Reporter: Manuel Dominguez Sarmiento We have a use case for eager fetching of an <any> association. The DTD accepts lazy="false|true", however at runtime it doesn't make any difference. Digging deeper, we see that org.hibernate.mapping.Any does not have a lazy property, furthermore, it does not extend Fetchable. This explains why it will not work as expected. There are two possible resolutions: 1) Implement eager fetching for <any> associations, unless there is some technical difficulty in doing so. Of course lazy fetching won't be possible using joins because of the nature of this type of associations, however it should be simple enough with a second select. This means that the XML config should handle lazy="false|true" but not fetch="join|select|subselect|etc" 2) Fix the DTD in case this can't be done to avoid confusion (less desirable). -- 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, 11 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-2484) Introduce NamingStrategy.getDefaultEntityName(String className)

by Emmanuel Bernard (JIRA)

Introduce NamingStrategy.getDefaultEntityName(String className) --------------------------------------------------------------- Key: HHH-2484 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2484 Project: Hibernate3 Type: Improvement Components: core Reporter: Emmanuel Bernard Assigned to: Emmanuel Bernard Priority: Minor Fix For: 3.3 -- 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, 12 months

2
6
0 / 0

[Hibernate-JIRA] Created: (HHH-3008) Cascade delete does not work with unidirectional @OneToMany and @JoinTable

by Daniel Dyer (JIRA)

Cascade delete does not work with unidirectional @OneToMany and @JoinTable -------------------------------------------------------------------------- Key: HHH-3008 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3008 Project: Hibernate3 Issue Type: Bug Affects Versions: 3.2.5 Environment: Standalone entity manager (JavaSE 5.0). H2 database. Reporter: Daniel Dyer A unidirectional one-to-many relationship defined as follows: public class Owner { @OneToMany(cascade = CascadeType.ALL) @JoinTable(name = "owner_element", joinColumns = @JoinColumn(name = "owner_id", nullable = false, updatable = false), inverseJoinColumns = @JoinColumn(name = "element_id", nullable = false, updatable = false)) private List<Element> elements; // ... } Attempting to delete an instance of Owner should also delete all associated instances of Element. Instead I get the following error: SEVERE: Referential integrity constraint violation: FK56BBF9C487E817D: PUBLIC.OWNER_ELEMENT FOREIGN KEY(OWNER_ID) REFERENCES PUBLIC.OWNER(ID) [23003-63] This is because Hibernate attempts to delete the Owner row without first removing the rows from the join 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

14 years, 12 months

3
4
0 / 0

[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

14 years, 12 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

15 years

9
15
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

15 years

3
2
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

15 years

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

15 years

4
3
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues March 2009