March 2009 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-2845) "Another ORA-00907: missing right parenthesis" bug with Oracle

by Dean Pullen (JIRA)

"Another ORA-00907: missing right parenthesis" bug with Oracle -------------------------------------------------------------- Key: HHH-2845 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2845 Project: Hibernate3 Issue Type: Bug Affects Versions: 3.2.5 Environment: hibernate-entitymanager.jar (3.3.1ga) hibernate-annotations.jar (v 3.3.0ga) hibernate-commons-annotations.jar (within Hibernate Annotations.rar\lib) ejb3-persistence.jar (within Hibernate Annotations.rar\lib) hibernate3.jar (v 3.2.5.ga) Oracle 10g Reporter: Dean Pullen I'm using JBoss 4.2.1GA, with the Hibernate environment described above, using Oracle 10g, and attempting to perform a query. I've been receiving a "ORA-00907: missing right parenthesis" error when attempting to perform the query. Now a similar bug had this down to Hibernate using the 'as' keyword in the query, aliasing the table name - something that has been fixed in Hibernate 3.3.0ga. (Aliasing a table in the SQL spec is optional, Oracle doesn't support it) But I still get the same error. The query still contains the 'as' keyword (but not aliasing a table) Here is an example: I have two tables. CSIUsers and CSIUserSurveys. There is a one-to-many mapping between CSIUsers to CSIUserSurveys. Query query = entityManager.createQuery("FROM " + CSIUser.class.getSimpleName() + " cu LEFT JOIN cu.csiUserSurveys us" + " WHERE NOT EXISTS (SELECT us FROM cu.csiUserSurveys us WHERE us.csiUserId = cu.csiUserId)"); Result: [[14 Sep 2007 15:43:52] DEBUG org.hibernate.util.JDBCExceptionReporter - could n ot execute query [select csiuser0_.CSI_USER_ID as CSI1_15_0_, csiusersur1_.CSI_U SER_ID as CSI1_16_1_, csiusersur1_.SURVEY_TYPE_CODE as SURVEY2_16_1_, csiuser0_. COMPANY_CODE as COMPANY2_15_0_, csiuser0_.EMAIL_ADDRESS as EMAIL3_15_0_, csiuser 0_.FAILED_LOGINS as FAILED4_15_0_, csiuser0_.LOCALE as LOCALE15_0_, csiuser0_.PA SSWORD as PASSWORD15_0_, csiuser0_.PURCHASE_DATE as PURCHASE7_15_0_, csiuser0_.S TATUS as STATUS15_0_, csiuser0_.USER_NAME as USER9_15_0_, csiuser0_.USER_PRIVILE GE as USER10_15_0_, csiusersur1_.SURVEY_INVITE_DATE as SURVEY3_16_1_ from CSI_US ERS csiuser0_ left outer join CSI_USER_SURVEYS csiusersur1_ on csiuser0_.CSI_USE R_ID=csiusersur1_.CSI_USER_ID where not (exists (select (csiusersur2_.CSI_USER_ ID, csiusersur2_.SURVEY_TYPE_CODE) from CSI_USER_SURVEYS csiusersur2_ where csiu ser0_.CSI_USER_ID=csiusersur2_.CSI_USER_ID and csiusersur2_.CSI_USER_ID=csiuser0 _.CSI_USER_ID))] java.sql.SQLException: ORA-00907: missing right parenthesis -- 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, 1 month

3
4
0 / 0

[Hibernate-JIRA] Created: (HHH-2480) Unify join fetch behavior or HQL and Criteria APIs

by Christian Bauer (JIRA)

Unify join fetch behavior or HQL and Criteria APIs -------------------------------------------------- Key: HHH-2480 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2480 Project: Hibernate3 Type: Improvement Components: query-hql, query-criteria Reporter: Christian Bauer Priority: Critical Fix For: 3.3 Can we consider changing the criteria API in 3.3 so that DISTINCT_ROOT_ENTITY is the default transformer? 10:28 I remember that detecting "fetch" in HQL and applying this transformer is already on the list, right? 10:29 or introduce config options for both APIs, so users can switch the default transformer 10:30 also, verify this please: http://www.hibernate.org/117.html#A12 Steve 2:31 we should try to detect if any fetches are present 2:31 otherwise DISTINCT_ROOT_ENTITY presents unecessary overhead 2:31 i dont recall such a discussion regarding that feature in HQL 2:32 another option is sorta like i'm planning in other areas: fallback to subselect fetching -- 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, 1 month

4
5
0 / 0

[Hibernate-JIRA] Created: (EJB-402) Ejb3ConfigurationObjectFactory needs to use MarshalledValueInputStream

by Galder Zamarreno (JIRA)

Ejb3ConfigurationObjectFactory needs to use MarshalledValueInputStream ---------------------------------------------------------------------- Key: EJB-402 URL: http://opensource.atlassian.com/projects/hibernate/browse/EJB-402 Project: Hibernate Entity Manager Issue Type: Bug Affects Versions: 3.4.0.CR2, 3.3.2.GA, 3.2.1 Reporter: Galder Zamarreno Assignee: Galder Zamarreno Fix For: 3.4.0.GA Ejb3ConfigurationObjectFactory should use MarshalledValueInputStream instead of ObjectInputStream, otherwise looking up configuration from isolated deployments won't work correcly and you'll get ClassNotFoundExceptions. MarshalledValueInputStream is different from ObjectInputStream in that it uses the thread context classloader to load classes rather than the system classloader. -- 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, 1 month

2
13
0 / 0

[Hibernate-JIRA] Created: (HHH-2935) Cascading save on OneToMany causes not null constraint violation on child table

by Aaron Luchko (JIRA)

Cascading save on OneToMany causes not null constraint violation on child table ------------------------------------------------------------------------------- Key: HHH-2935 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2935 Project: Hibernate3 Issue Type: Bug Affects Versions: 3.2.1 Environment: hibernate-3.2.1, hibernate-annotations-3.2.1 Reporter: Aaron Luchko Attachments: saveNull.zip When defining a OneToMany relationship, controlled by the parent, and not nullable by the child, there's an issue when trying to insert the initially created columns. With a schema attached as thus public class Parent { ... @OneToMany(targetEntity = Child.class, cascade = { CascadeType.ALL }) @Cascade( { org.hibernate.annotations.CascadeType.SAVE_UPDATE, org.hibernate.annotations.CascadeType.DELETE_ORPHAN }) @JoinColumn(name = "parent_child") public List<Child> getChildren() { return children; } } public class Child{ ... @ManyToOne @JoinColumn(name = "parent_child", insertable = false, updatable = false, nullable=false) public Parent getParent() { return parent; } } And running a section of code such as this Session session = HibernateUtil.getSession(); session.beginTransaction(); Parent parent = new Parent(); int times = 2; List<Child> children = new ArrayList<Child>(times); for (int i = 0; i < times; i++) { Child child = new Child(); children.add(child); child.setParent(parent); } parent.setChildren(children); session.save(parent); session.getTransaction().commit(); Hibernate attempts to run the following series of queries select child_.id from Child child_ where child_.id=? select child_.id from Child child_ where child_.id=? insert into Parent (id) values (?) insert into Child (id) values (?) insert into Child (id) values (?) update Child set parent_child=? where id=? update Child set parent_child=? where id=? The problem is that in initial batch inserting the two children fails violating the not null constraint before the update can assign a value to parent_child. I've reproduced this with postgresql and mysql (after setting the dialect to org.hibernate.dialect.MySQLInnoDBDialect, MyISAM doesn't catch the constraint violation). As a workaround one can simply leave off the nullable=false. I've attached a full testcase. thanks, Aaron -- 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, 1 month

2
1
0 / 0

[Hibernate-JIRA] Created: (HV-38) Conditional validation

by Bruno Braga (JIRA)

Conditional validation ---------------------- Key: HV-38 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-38 Project: Hibernate Validator Issue Type: Improvement Components: engine Affects Versions: 3.0.0.ga Reporter: Bruno Braga Priority: Critical Support Conditional Validation Example: @NotNull(apply-if="some condition in el") I can develop this if you approve. -- 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, 1 month

3
9
0 / 0

[Hibernate-JIRA] Created: (HHH-2272) Serious performance problems when saving large amount of transient entities with collections of transient entities

by Markus Heiden (JIRA)

Serious performance problems when saving large amount of transient entities with collections of transient entities ------------------------------------------------------------------------------------------------------------------ Key: HHH-2272 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2272 Project: Hibernate3 Type: Task Components: core Versions: 3.2.0.ga Environment: Hibernate 3.2.0 on Oracle 9.2 Reporter: Markus Heiden When saving many (e.g. 50000) transient entities with a collection of transient entities, for each collection element the whole persistence context is searched (by StatefulPersistenceContext#getIndexInOwner() and StatefulPersistenceContext#getOwnerId) and its even searched twice when the collection is an indexed collection. This leads to an enormous amount (> 1000000) of iterations over all entities and over all collection elements of each entity. Especially when one saves only the same type of entities this leads to times of hours(!) even on a fast machine before any insert statement is even issued. This issue is related to HHH-1612, but fixing issue HHH-1612 won't resolve this problem (I have explored this with a hack which fixes HHH-1612). In my eyes there are two ways to solve this problem: 1) When cascading the save of a parent, the parent cascade can fill the persistence context with information about its collection elements. E.g. before cascading the save to a collection a parent can add a (child, parent) pair to a map in the persistence context to avoid the above described iterations. Then a simple Map#get() would be sufficient in most cases to get the parent. 2) When cascading, the parent has to be passed with the cascaded (e.g. saved) element. But this is no good solution, because it affects some well known hibernate apis. -- 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, 1 month

5
13
0 / 0

[Hibernate-JIRA] Created: (HHH-3271) Prepare Statement Caching

by lalit railwani (JIRA)

Prepare Statement Caching ------------------------- Key: HHH-3271 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3271 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.5 Environment: Hibernate 3.2.5, Oracle 10g Reporter: lalit railwani We are using Hibernate 3.2.5 are trying to evaluate hibernate batching vis a vis JDBC batching. As per our results the hibernate batching takes approx 2 times the time taken by JDBC batching. The problem is we need to commit the batches also so in a loop we are commiting the transaction also (batching). But for every new loop hibernate creates new prepared statements i.e. if we have 20 batches 20 prepared statements per table/entity are being created but in case of JDBC the same can be done using 1 prepared statement per table/entity. Hibernate does reuse the prepared statements within a batch but not across batches. If hibernate can reuse these statements it would significantly reduce the timings and would bring the hibernate batching close to jdbc batching. This is happening even after enabling prepare statement caching in the hibernate cfg xml. -- 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, 1 month

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-3578) Add setReadOnly(true) method to the Criteria interface

by Graeme Rocher (JIRA)

Add setReadOnly(true) method to the Criteria interface ------------------------------------------------------ Key: HHH-3578 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3578 Project: Hibernate Core Issue Type: New Feature Components: core Affects Versions: 3.3.1, 3.3.0.SP1, 3.3.0.GA, 3.3.0.CR2, 3.3.0.CR1, 3.2.6, 3.2.5, 3.2.4.sp1, 3.2.4, 3.2.3, 3.2.2, 3.2.1, 3.2.0.ga, 3.2.0.cr5, 3.2.0.cr4, 3.2.0.cr3, 3.2.0.cr2, 3.2.0 cr1, 3.1.3, 3.2.0.alpha2, 3.2.0.alpha1, 3.1.2, 3.1.1, 3.1, 3.1 rc3, 3.1 rc2, 3.1 rc 1, 3.1 beta 2, 3.1 beta 1, 3.0.5, 3.0.4, 3.0.3, 3.0.2, 3.0.1, 3.0 final, 3.0 rc 1, 3.0 beta 4, 3.0 beta 3, 3.0 beta 2, 3.0 beta 1, 3.0 alpha Reporter: Graeme Rocher Currently the Query interface has a setReadOnly(true) method but the Criteria interface does not, this makes it impractical to use the Criteria API for read-only queries. -- 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, 1 month

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-3772) Constraint names cannot be quoted with backticks `

by Christian (JIRA)

Constraint names cannot be quoted with backticks ` -------------------------------------------------- Key: HHH-3772 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3772 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.1 Environment: Hibernate 3.3, all database dialects Reporter: Christian Priority: Minor Table and Column names can be quoted with ` but constraint names cannot be quoted. You can reproduces the bug with the following testcase: @javax.persistence.Entity @javax.persistence.Table( name = "`categories`" ) abstract public class Category { ... @org.hibernate.annotations.ForeignKey( name = "`fk_categories_parent_id`" ) @javax.persistence.ManyToOne( targetEntity = Category.class ) @javax.persistence.JoinColumn( name = "`parent_id`" ) private Category parent; ... } The SchemaExport (hbm2ddl) creates the following SQL statement for Postgresql: alter table "categories" drop constraint `fk_categories_parent_id`; drop table "categories"; create table "categories" ( ... "parent_id" int8, ... ); alter table "categories" add constraint `fk_categories_parent_id` foreign key ("parent_id") references "categories"; I think this problem should be fixed in the method in the class org.hibernate.mapping.Constraint in the same way as in Table.java and Column.java: old: public void setName(String name) { this.name = name; } new: private boolean quoted = false; public void setName(String name) { if ( name.charAt( 0 ) == '`' ) { quoted = true; this.name = name.substring( 1, name.length() - 1 ); } else { this.name = name; } } public String getQuotedName() .. same as in Column.java public String getQuotedName(Dialect d) { .. same as in Column.java public boolean isQuoted() .. same as in Column.java public String sqlDropString( ... ) { ... return "alter table " + getTable().getQualifiedName( dialect, defaultCatalog, defaultSchema ) + " drop constraint " + getQualifiedName(); ... } public String sqlCreateString( ... ) { ... String constraintString = sqlConstraintString( dialect, getQualifiedName(), defaultCatalog, defaultSchema ); ... } -- 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, 1 month

2
1
0 / 0

[Hibernate-JIRA] Created: (HBX-936) Project cannot be deleted when there is console configuration associated with the project

by Dariusz Tylus (JIRA)

Project cannot be deleted when there is console configuration associated with the project ----------------------------------------------------------------------------------------- Key: HBX-936 URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-936 Project: Hibernate Tools Issue Type: Bug Components: consoleconfiguration, eclipse Affects Versions: 3.2beta9 Environment: Eclipse 3.2, Windows XP, jdk1.5.0_8 Reporter: Dariusz Tylus Project cannot be deleted when there is console configuration associated with the project: Use case: 1. Create java project 2. Put jdbc driver jar file into lib filder (in the project) 3. Create console configuration for this project 4. Swich to the hibernate perspective and expand the tree for just created console configuration 5. Delete the console configuration 6. Delete the project and select option 'Also delete contents under....' There is following error: == Problems encountered while deleting resources. Could not delete: /hbmtest. Problems encountered while deleting resources. Problems encountered while deleting files. Could not delete: C:\work\ORM\_tests\orm\hbmtest\lib\hsqldb-1_7_2_9.jar. Could not delete: C:\work\ORM\_tests\orm\hbmtest\lib. == The problem is that jvm keeps lock on the jar file so it cannot be deleted. Console configuration also keeps reference to the driver class. Could the console configuration release all resources when it is deleted? Thenx, Dariusz -- 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, 1 month

2
5
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues March 2009