March 2007 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-2289) CLONE -Support new MySQL 5.0.12 join syntax

by Peter Lundberg (JIRA)

CLONE -Support new MySQL 5.0.12 join syntax ------------------------------------------- Key: HHH-2289 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2289 Project: Hibernate3 Type: New Feature Components: query-sql Versions: 3.1.2 Reporter: Peter Lundberg http://dev.mysql.com/doc/refman/5.0/en/join.html "Beginning with MySQL 5.0.12, natural joins and joins with USING, including outer join variants, are processed according to the SQL:2003 standard. These changes make MySQL more compliant with standard SQL. However, they can result in different output columns for some joins. Also, some queries that appeared to work correctly in older versions must be rewritten to comply with the standard. The following list provides more detail about several effects of the 5.0.12 change in join processing. The term "previously" means "prior to MySQL 5.0.12." Using 5.0.18 and hibernate 3.1.2, hibernate is not producing the correct join syntax for the latest versions of mysql. For example: FROM tableA AS A, tableB AS B INNER JOIN tableC AS C ON A.field1 = C.field2 The above fails, because the B JOIN C is evaluated before the A alias has been created. The solution is to use parentheses to force an order of evaluation: FROM (tableA AS A, tableB AS B) INNER JOIN tableC AS C ON A.field1 = C.field2 -- 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

16 years, 10 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-2106) * criteria queries

by Toby (JIRA)

* criteria queries ------------------ Key: HHH-2106 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2106 Project: Hibernate3 Type: New Feature Components: query-criteria Reporter: Toby -localArea -wideArea - country Imagine you want to query local area that belong to a country, independet of the "wide area". But country is only references via a wide area and there is no direct link between local area and a country. You can not add wide area as a restriction as the problem ist, that you want all wide areas....and you only need them to get to the county..... Criteria c = session.createCriteria(LocalArea.class); c.add(Restrictions.eq("wideArea", *)); c.add(Restrictions.eq("country", country)); -- 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

16 years, 10 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-2164) Minor bug in section "20.1.1. Customizing the schema"

by Andres Gonzalez (JIRA)

Minor bug in section "20.1.1. Customizing the schema" ----------------------------------------------------- Key: HHH-2164 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2164 Project: Hibernate3 Type: Bug Components: documentation Versions: 3.2.0.ga Reporter: Andres Gonzalez Where it says: ******************************************************************************************************************************* A unique-key attribute may be used to group columns in a single unique key constraint. Currently, the specified value of the unique-key attribute is not used to name the constraint in the generated DDL, only to group the columns in the mapping file. <many-to-one name="org" column="orgId" unique-key="OrgEmployeeId"/> <property name="employeeId" unique-key="OrgEmployee"/> ******************************************************************************************************************************* i think the unique-key attributes should jave both the same value ("OrgEmployee", for example) -- 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

16 years, 10 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-2369) Documentation doesn't state what hibernate returns for empty/null collections

by James Roper (JIRA)

Documentation doesn't state what hibernate returns for empty/null collections ----------------------------------------------------------------------------- Key: HHH-2369 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2369 Project: Hibernate3 Type: Improvement Components: documentation Versions: 3.2.1 Reporter: James Roper Priority: Trivial Reading the hibernate documentation, section 6.1: "Hibernate does not distinguish between a null collection reference and an empty collection" This is all very well, but what does hibernate return when loading a null/empty collection? According to the EJB3 specification, section 2.1.7: "If there are no associated entities for a multi-valued relationship of an entity fetched from the database, the persistence provider is responsible for returning an empty collection as the value of the relationship." If this is the behavior that hibernate implements, then this should be explicitly stated in the hibernate documentation, so that developers know whether they need to do null checks or not after loading an object from the database. -- 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

16 years, 10 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-2468) Is setParameter 0- or 1-based?

by Rafael Borges (JIRA)

Is setParameter 0- or 1-based? ------------------------------ Key: HHH-2468 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2468 Project: Hibernate3 Type: Bug Versions: 3.2.2 Environment: Hibernate 3.2.2.GA, RDBMS: H2, version: 1.0 (2007-01-30), JDK 6.0, Windows XP Pro Reporter: Rafael Borges Priority: Trivial The following query throws a wrong message in the Exception == Query == query = session.createQuery("select t from Test t where t.id = ?"); query.setParameter(1, 1); == Message == Exception in thread "main" java.lang.IndexOutOfBoundsException: Remember that ordinal parameters are 1-based! at org.hibernate.engine.query.ParameterMetadata.getOrdinalParameterDescriptor(ParameterMetadata.java:55) at org.hibernate.engine.query.ParameterMetadata.getOrdinalParameterExpectedType(ParameterMetadata.java:61) at org.hibernate.impl.AbstractQueryImpl.determineType(AbstractQueryImpl.java:397) at org.hibernate.impl.AbstractQueryImpl.setParameter(AbstractQueryImpl.java:369) at Test.main(Test.java:25) The Javadoc says it is 0-based, and that works perfectly when used accordingly. So I think it is just a comestic fix. -- 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

16 years, 10 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HHH-2519) Schema dropping not documented with hibernate.hbm2ddl.auto=create

by Ville Skyttä (JIRA)

Schema dropping not documented with hibernate.hbm2ddl.auto=create ----------------------------------------------------------------- Key: HHH-2519 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2519 Project: Hibernate3 Issue Type: Patch Components: documentation Environment: svn trunk Reporter: Ville Skyttä Attachments: create-drops.patch Dropping the schema is not documented with hibernate.hbm2ddl.auto=create, fix attached. -- 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

16 years, 10 months

2
1
0 / 0

[Hibernate-JIRA] Created: (ANN-530) introduce fetch_size for Hibernate Search scrollable resultsets.

by Emmanuel Bernard (JIRA)

introduce fetch_size for Hibernate Search scrollable resultsets. ---------------------------------------------------------------- Key: ANN-530 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-530 Project: Hibernate Annotations Type: New Feature Components: search Reporter: Emmanuel Bernard -- 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

16 years, 11 months

2
5
0 / 0

[Hibernate-JIRA] Created: (HBX-915) CLONE -Hibernate ant task does not work in a multi-project Maven 2 build if other mojos use javax.xml.transform

by Brill Pappin (JIRA)

CLONE -Hibernate ant task does not work in a multi-project Maven 2 build if other mojos use javax.xml.transform --------------------------------------------------------------------------------------------------------------- Key: HBX-915 URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-915 Project: Hibernate Tools Type: Bug Components: ant Versions: 3.1beta4 Environment: Hibernate 3.1, database is Oracle (but not relevant to this) Reporter: Brill Pappin Fix For: 3.2beta7 I have a reasonably complex maven 2 build with multiple projects. More than one of the projects uses the hbm2java task and at least one of the projects uses the Codehaus xslt-maven-plugin. When running the project that uses both hbm2java and XSLT, it works fine. But running the master build throws the following error. org.apache.maven.lifecycle.LifecycleExecutionException: Error executing ant tasks at org.apache.maven.lifecycle.DefaultLifecycleExecutor.executeGoals(DefaultLifecycleExecutor.java:559) [snip] Caused by: java.lang.IllegalStateException: 3.1.0.beta4 found when setting version at org.hibernate.tool.hbm2x.TemplateHelper.putInContext(TemplateHelper.java:223) [snip] I can't really explain where this error is coming from. I looked at the source for putInContext and it is using the Plexus options class and failing because the value of "version" is already in the options. I assumed from this it was a problem with the xstl-maven-plugin from Codehaus also using some Plexus libraries, but I refactored the mojo so it was ONLY using javax.xml.transform and the problem remained. I then changed my slimmed down mojo to force use of Saxon instead of the default JAXP implementation (Xalan?). .. and it worked fine! So this is definitely a problem with the instantiation of the default XSLT functionality in JDK1.4, although how that can possibly affect the build in this way is beyond me. You might consider this a Maven bug but it's very strange that it doesn't happen for any old mojo combination. I also think it is probably much easier to fix in Hibernate tools than in Maven. I'd suggest a couple of possible fixes/improvements: - Make "version" key more specific, eg. hibernate.tools.version to avoid possible clash with other Plexus clients in the same JVM - Don't throw an exception on any existing value being set as it is now but compare the value in the options to the new value and only throw an exception if they differ I can't think of a way to track down the underlying cause of this issue. It's a very odd one. Attached is a simple three project build to reproduce the problem. Just run 'mvn clean package' on the parent project to reproduce. -- 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

16 years, 11 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-2342) support <load-collection> for stored procedures (see 3.2 documentation section 16.2.2)

by Rick Bradshaw (JIRA)

support <load-collection> for stored procedures (see 3.2 documentation section 16.2.2) -------------------------------------------------------------------------------------- Key: HHH-2342 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2342 Project: Hibernate3 Type: New Feature Components: core Environment: Any new hibernate version/update - Oracle is my personal DBMS preference Reporter: Rick Bradshaw In the 3.2 documentation 16.2.2 "Using Stored Procedures for Querying" it specifies that "<load-collection>" is not supported. The ability to load collections from stored procedures is a powerful idea. I have done it manually within my own Java implementation and it is a big time / headache saver. Many of the DB models I work with (and don't have control of) are full of inconsistencies that can be re-modeled and disguised within a stored procedure that returns sys_refcursor. Adding the <load-collection> feature will make it really easy/fast to map into hibernate the result sets of stored procedures. -- 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

16 years, 11 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-2152) Optimistic lock error although using LockMode.UPGRADE

by Per-Olov Wingren (JIRA)

Optimistic lock error although using LockMode.UPGRADE ----------------------------------------------------- Key: HHH-2152 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2152 Project: Hibernate3 Type: Bug Components: core Versions: 3.1.3 Environment: Oracle 10.2, Hibernate 3.1.3 Reporter: Per-Olov Wingren Priority: Critical Attachments: OptLockProblem.zip I have a situation where two threads tries to update the same entity object at the same time. I use the Hibernate managed versioning using a version number but also a pessimistic lock using LockMode.UPGRADE. One thread will lock the object in the database and the other will wait for the transaction of the first thread to commit (or rollback). The first thread updates the object, which also will make its version to be incremented. When the second tread get access to the object after the first is commited, it get an incorrect value of the version attribute. This leads to a StaleObjectStateException when the transaction is commited. The entity object conists of a parent class and a subclass mapped to the database into two tables using <joined-subclass>. If the testcase is modified to update an attribute in the subclass (numberB) instead of in the superclass it works without errors. Is the problem caused by the fact that Hibernate only locks the subclass in the database (for update of classb.oid) and not the superclass? I attache a zip file containing a simple but complete test case that shows the problem. -- 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

16 years, 11 months

3
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues March 2007