October 2006 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Commented: (HHH-1423) ParameterParser bug - ordinal parameter mismatch

by john guthrie (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1423?page=c... ] john guthrie commented on HHH-1423: ----------------------------------- there is a workaround, at least for some (read "my") cases. just make sure that the 'call'-variable is the first in the query. for me this meant changing: from Ship s where s.name = ? and s.callsign = ? to from Ship s where s.callsign = ? and s.name = ? > ParameterParser bug - ordinal parameter mismatch > ------------------------------------------------- > > Key: HHH-1423 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1423 > Project: Hibernate3 > Type: Bug > Components: query-hql > Versions: 3.1.2 > Environment: Windows XP SP2, JDK 1.5.0_06-b05, Spring 1.2.6, antlr-2.7.6rc1 > Reporter: Artur Wronski > Priority: Critical > Attachments: HHH1423Test.java, ParameterParser.2.patch, ParameterParser.3.patch, ParameterParser.patch, RecognizerBug.java > > > There is still problem with ParameterParser. The same was in Hibernate 3.1.1 > Runnable TestCase in attachment. -- 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, 6 months

1
0
0 / 0

[Hibernate-JIRA] Commented: (HHH-1690) collection (set) always treated as dirty if it consists of composite-elements

by Michael Prescott (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1690?page=c... ] Michael Prescott commented on HHH-1690: --------------------------------------- I ask because I have a scenario where the default (Object) semantics are acceptable to me, and we're never comparing these elements across sessions. Nevertheless, a one-element set is always marked as dirty. > collection (set) always treated as dirty if it consists of composite-elements > ----------------------------------------------------------------------------- > > Key: HHH-1690 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1690 > Project: Hibernate3 > Type: Bug > Components: core > Versions: 3.1.3 > Environment: jdk1.5 > Reporter: Renat Araslanow > > > collection (set) always treated as dirty if it consists of composite-elements (lazy and access type doesn't matter). > if i change composite-element to element with type string all is all right. > User.hbm.xml > <set name="z" access="field" table="user_roles" lazy="false"> > <key column="account_id"/> > <composite-element class="indoors.model.UserRole"> > <property name="role" not-null="true" type="string"/> > </composite-element> > </set> > User.java (only that relate to collection this single line) > ... > private Set z = new HashSet(); > ... > UserRole.java > public class UserRole > { > private String role; > public String getRole() > { > return role; > } > public void setRole( String role ) > { > this.role = role; > } > } -- 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, 6 months

1
0
0 / 0

[Hibernate-JIRA] Commented: (HHH-1690) collection (set) always treated as dirty if it consists of composite-elements

by Michael Prescott (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1690?page=c... ] Michael Prescott commented on HHH-1690: --------------------------------------- Is it acceptable not to implement them, if the default implementation meets your domain's business semantics? Or is it always necessary to reimplement them for sets of composite elements? > collection (set) always treated as dirty if it consists of composite-elements > ----------------------------------------------------------------------------- > > Key: HHH-1690 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1690 > Project: Hibernate3 > Type: Bug > Components: core > Versions: 3.1.3 > Environment: jdk1.5 > Reporter: Renat Araslanow > > > collection (set) always treated as dirty if it consists of composite-elements (lazy and access type doesn't matter). > if i change composite-element to element with type string all is all right. > User.hbm.xml > <set name="z" access="field" table="user_roles" lazy="false"> > <key column="account_id"/> > <composite-element class="indoors.model.UserRole"> > <property name="role" not-null="true" type="string"/> > </composite-element> > </set> > User.java (only that relate to collection this single line) > ... > private Set z = new HashSet(); > ... > UserRole.java > public class UserRole > { > private String role; > public String getRole() > { > return role; > } > public void setRole( String role ) > { > this.role = role; > } > } -- 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, 6 months

1
0
0 / 0

[Hibernate-JIRA] Closed: (HBX-95) create a hbmlint

by Max Rydahl Andersen (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HBX-95?page=all ] Max Rydahl Andersen closed HBX-95: ---------------------------------- Fix Version: 3.2beta9 (was: 3.2LATER) Resolution: Fixed <hibernatetool> <...configuration/> <hbmlint/> </hibernatetool> hbmlint-result.txt: CACHE_COLLECTION_NONCACHABLE_TARGET:Entity 'org.hibernate.tool.hbmlint.Category' is referenced from the cache-enabled collection 'org.hibernate.tool.hbmlint.Category.childCategories' without the entity being cachable LAZY_NOT_INSTRUMENTED:'org.hibernate.tool.hbmlint.BrokenNonLazy' has lazy='false', but its class 'org.hibernate.tool.hbmlint.BrokenNonLazy' has not been instrumented with cglib LAZY_NO_DEFAULT_CONSTRUCTOR:lazy='true' set for 'org.hibernate.tool.hbmlint.BrokenLazy', but class has no default constructor. ID_SHADOWED:org.hibernate.tool.hbmlint.IdentifierProblem has a normal property named 'id'. This can cause issues since HQL queries will always interpret 'id' as the identifier and not the concrete property SCHEMA_TABLE_MISSING:Missing table BrokenLazy SCHEMA_TABLE_MISSING:Missing table BrokenNonLazy SCHEMA_TABLE_MISSING:Missing table Category SCHEMA_TABLE_MISSING:Missing table FakeNonLazy SCHEMA_TABLE_MISSING:Missing table IdentifierProblem SCHEMA_TABLE_MISSING:Missing table NoTable SCHEMA_COLUMN_TYPE_MISMATCH:BadType has a wrong column type for name, expected: CLOB but was VARCHAR in db SCHEMA_COLUMN_MISSING:Category is missing column: name SCHEMA_TABLE_MISSING:Missing table MissingTable MISSING_ID_GENERATOR:Missing sequence or table: hibernate_unique_key This is the first cut so the output is just a raw dump of the issues found - should be beefed up and with links to an explanation of the problem found instead of repeating it always etc. > create a hbmlint > ---------------- > > Key: HBX-95 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-95 > Project: Hibernate Tools > Type: New Feature > Reporter: Max Rydahl Andersen > Fix For: 3.2beta9 > > > We should create a hbmlint that checks if once hibernate configuration and mapping is correct/suited for production. > Main function would be to check if the hibernate mappings corresponds to what is in the database (does table, column, foreignkey etc. match) > Secondary could be to check that dialect matches database, no use of hibernate development only connectionpool, deep inheritance hiearchies etc. -- 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, 6 months

1
0
0 / 0

[Hibernate-JIRA] Commented: (HHH-1273) Remove persist() on Session API

by Christian Bauer (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1273?page=c... ] Christian Bauer commented on HHH-1273: -------------------------------------- In case anybody finds this thread... persist() is well defined. It makes a transient instance persistent. However, it doesn't guarantee that the identifier value will be assigned to the persistent instance immediately, the assignment might happen at flush time. The spec doesn't say that, which is the problem I have with persist(). persist() also guarantees that it will not execute an INSERT statement if it is called outside of transaction boundaries. This is useful in long-running conversations with an extended Session/persistence context. A method like persist() is required. save() does not guarantee the same, it returns an identifier, and if an INSERT has to be executed to get the identifier (e.g. "identity" generator, not "sequence"), this INSERT happens immediately, no matter if you are inside or outside of a transaction. This is not good in a long-running conversation with an extended Session/persistence context. > Remove persist() on Session API > ------------------------------- > > Key: HHH-1273 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1273 > Project: Hibernate3 > Type: Improvement > Components: core, documentation > Reporter: Christian Bauer > > > This is from a user/documentatio perspective, completely ignoring any reason on the implementation side. Stay with me. > The persist() operation on Session is not cascaded at flush time. This is somewhat unexpected from a users point of view and very difficult to explain and understand (you need excellent knowledge of flushing and cascading). Reason #1 for removal. > The persist() operation in general does not return a database identifier. This is surprising, as the JPA spec clearly requires a persistent instance to have a database identifier value. Since persist() makes instances persistent, it has to have the same semantics for assigning identifiers as save(). Hence, I expect that once this mismatch is resolved in the expert group, the persist() method will return a database identifier. Everything else doesn't make much sense, given the current specification and documentation. Conclusion is that persist() will have the same signature as save(). Reason #2 for removal. > To document persist() properly I need a reason for its existence. Right now I'm telling readers/users to ignore it on the Session API, because it only complicates the situation with no benefit. -- 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, 6 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HBX-775) Graphs fail for entities with Set collections

by Mark Hobson (JIRA)

Graphs fail for entities with Set collections --------------------------------------------- Key: HBX-775 URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-775 Project: Hibernate Tools Type: Bug Components: visualizations Versions: 3.2beta8 Reporter: Mark Hobson Attachments: patch.txt Looks like Sets were neglected from EntityNameFromValueVisitor. Fixed in attached patch. -- 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, 6 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-2143) Add support for projection to the Query API as in the Criteria API to ease automated pagination of HQL queries

by Cédric Vidal (JIRA)

Add support for projection to the Query API as in the Criteria API to ease automated pagination of HQL queries -------------------------------------------------------------------------------------------------------------- Key: HHH-2143 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2143 Project: Hibernate3 Type: Improvement Components: query-hql Reporter: Cédric Vidal Today, both the Criteria and Query APIs have setMaxResults and setFirstResult methods. Thanx to these methods, it is really easy to add pagination to an existing Criteria or Query in technical code in order to remove that consideration from user code. But, most of the time, it is also necessary to display the total number of records or the number of pages which either way requires to fetch the total number of records which would be returned by the query. The Criteria API introduced the setProjection(Projection) method which elegantly enables to do just that: // User code Criteria existingCriteria = session.createCriteria(Cat.class); // Technical Pagination code Integer count = (Integer)existingCriteria .setProjection( Projections.rowCount() ) .uniqueResult(); The problem is that the Query API lacks the setProjection method. Today, with an HQL query, one has to manually write in user code the additional count(*) specific query that returns the total number of results. It would be very usefull as well as time saving to be able to do the same as in the Query API: // User code Query existingQuery = session.createQuery("from Cat") // Technical Pagination code Integer count = (Integer)existingQuery .setProjection( Projections.rowCount() ) .uniqueResult(); Regards, Cédric Vidal -- 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, 6 months

2
1
0 / 0

[Hibernate-JIRA] Commented: (HHH-1) Optimize Hibernate for the bulk insertion of related entities

by Michael Kopp (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1?page=comm... ] Michael Kopp commented on HHH-1: -------------------------------- HI Martin, I hadn't had the time to do that patch. or better I hadn't had the time to properly test and submit it. maybe you can do that. All you have to do is to add the following to the EntitiyInsertAction public int compareTo(Object other) { if (other == this) return 0; try { final EntityInsertAction entityInsertAction = ((EntityInsertAction) other); final Object instance = entityInsertAction.getInstance(); if (instance != getInstance()) { // if any of our properties is actually to be inserted, it has to be before us for (int i = 0; i < state.length; i++) { final Object rel = state[i]; if (rel == instance) return +1; // the 'other' InsertAction inserts something that we need. it has to be before us in the queue } } } catch (ClassCastException e) { // why would we compare against another object than one with the same type... } return super.compareTo(other); } It makes sure that (upon sorting) an instance gets always inserted before the referal to that instance. After that you just have to sort the inserts like hibernate sorts the updates (can be configured) e.g. change the ActionQueue.sortUpdateActions and add a sort for the inserts. That should do it. > Optimize Hibernate for the bulk insertion of related entities > ------------------------------------------------------------- > > Key: HHH-1 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1 > Project: Hibernate3 > Type: New Feature > Components: core > Environment: Hibernate 1.2, MySql 3.1 > Reporter: Bradley Leupen > Priority: Minor > > > It is currently difficult to batch the creation of persistent entities that maintain associations with other entities. > Add necessary api to hibernate to support the save or update of a collection of entities. An optimization can be applied in this scenario to group inserts / updates by entity class, or table. This will enable the hibernate engine to utilize batching if available, drastically improving performance over a network. -- 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, 6 months

1
0
0 / 0

[Hibernate-JIRA] Commented: (HHH-1) Optimize Hibernate for the bulk insertion of related entities

by Martin Ross (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1?page=comm... ] Martin Ross commented on HHH-1: ------------------------------- Michael, Is there any update on this? We do large complex object inserts and would greatly benefit from this type of functionality. We would be willing to pay for this feature to be implemented as it is really critical for us. Thanks, Martin > Optimize Hibernate for the bulk insertion of related entities > ------------------------------------------------------------- > > Key: HHH-1 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1 > Project: Hibernate3 > Type: New Feature > Components: core > Environment: Hibernate 1.2, MySql 3.1 > Reporter: Bradley Leupen > Priority: Minor > > > It is currently difficult to batch the creation of persistent entities that maintain associations with other entities. > Add necessary api to hibernate to support the save or update of a collection of entities. An optimization can be applied in this scenario to group inserts / updates by entity class, or table. This will enable the hibernate engine to utilize batching if available, drastically improving performance over a network. -- 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, 6 months

1
0
0 / 0

[Hibernate-JIRA] Commented: (ANN-103) Allow to specify fetching strategy for secondary table

by Christian Bauer (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/ANN-103?page=co... ] Christian Bauer commented on ANN-103: ------------------------------------- I'm surprised that you didn't attach a patch. > Allow to specify fetching strategy for secondary table > ------------------------------------------------------ > > Key: ANN-103 > URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-103 > Project: Hibernate Annotations > Type: New Feature > Components: binder > Reporter: Christian Bauer > Priority: Minor > > > Right now a secondary table always defaults to optional="true" and fetch="join". I don't see a real value in optional="false" anyway, but fetch="select" might be useful. -- 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, 6 months

1
0
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 October 2006