April 2009 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-3880) "AS"-alias Bug under Postgresql

by dnalos (JIRA)

"AS"-alias Bug under Postgresql ------------------------------- Key: HHH-3880 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3880 Project: Hibernate Core Issue Type: Bug Affects Versions: 3.3.1 Environment: Hibernate Core 3.3.1 PostgreSQL 8.3 Reporter: dnalos I have reporte this problem in forum, but it rebuilding now, so i create a jira task. We use org.hibernate.id.enhanced.SequenceStyleGenerator to generate our id. The tests running under mysql and hsql, but not under postgres. And we find a small bug in org.hibernate.id.enhanced.TableStructure, the constructor of this class maked e.g. the select script: select next_val id_val from hibernate_sequence for update But in Postgresql neds "as" between next_val and id_val. See this sentence from PostgreSQL (http://sql-info.de/en/postgresql/postgres-gotchas.html#1_1): In the SQL92 standard, the optional keyword AS is just noise and can be omitted without affecting the meaning. The PostgreSQL parser requires this keyword when renaming output columns because the type extensibility features lead to parsing ambiguities in this context. AS is optional in FROM items, however. -- 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, 2 months

3
6
0 / 0

[Hibernate-JIRA] Created: (HHH-3589) Sql generated for criteria intermittently causes "invalid identifier" error by assigning incorrect table alias to query elements

by Todd Currie (JIRA)

Sql generated for criteria intermittently causes "invalid identifier" error by assigning incorrect table alias to query elements -------------------------------------------------------------------------------------------------------------------------------- Key: HHH-3589 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3589 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.1 Environment: Hibernate Core 3.3.1.GA Oracle 10.02.03 JRE Q1.5.0_16-b02 Reporter: Todd Currie Application is encountering intermittent ORA-00904 "invalid identifier" errors in production and test build environment. Error occurs approximately 1:460 executions in the test build environment. In each occurence it happens with a different test, but when it occurs every criteria query generated for that test class fails. In production typically causes application to crash because of the unexpected exception thrown. The issue appears to be caused during construction of the CriteriaJoinWalker. The CriteriaLoader creates a CriteriaQueryTranslator that is responsible for the where condition and order by for non-projection queries (or additionally the select and group by for projection queries). The translator constructor is passed the CriteriaQueryTranslator.ROOT_SQL_ALIAS, "this_", which it uses for its rootSQLAlias. But when the CriteriaLoader next creates the CriteriaJoinWalker instance that is responsible for the rest of the query elements, it does not use the constructor that takes the root alias. The CriteriaJoinWalker then calls super(persister, factory, enabledFilters, alias); with a null passed in the alias parameter. The constructor in the parent class, AbstractEntityJoinWalker, calls generateRootAlias when the alias parameter is null. The method generateRootAlias is implemented both in the parent class JoinWalker and the child class CriteriaJoinWalker. To implement this form of polymorphism, java uses dynamic method binding to determine which method to call for the instance at run time. It appears that most of the time it calls the CriteriaJoinWalker implementation of generateRootAlias function which is hard coded to return CriteriaQueryTranslator.ROOT_SQL_ALIAS, "this_". The queries then generated by the CriteriaJoinWalker then execute correctly. But intermittently it calls the JoinWalker implementation which uses the passed in persistor's entityName to generate the table alias. This table alias that is then used for the rest of the query is different then the alias used by the CriteriaQueryTranslator and the resulting sql generates the invalid identifier error seen upon execution. This can be fixed in a number of ways. 1) pass the CriteriaQueryTranslator.ROOT_SQL_ALIAS into the constructor for the CriteriaJoinWalker. 2) make the generateRootAlias abstract in the JoinWalker (less reliable). 3) use an AbstractFactory pattern to construct the objects (more work). I have implemented #1 in our environment and am working on generating a clean test case to submit here. But for those who are interested here is the patch: ### Eclipse Workspace Patch 1.0 #P hibernate-core Index: src/main/java/org/hibernate/loader/criteria/CriteriaLoader.java =================================================================== --- src/main/java/org/hibernate/loader/criteria/CriteriaLoader.java (revision 15443) +++ src/main/java/org/hibernate/loader/criteria/CriteriaLoader.java (working copy) @@ -94,7 +94,8 @@ factory, criteria, rootEntityName, - enabledFilters + enabledFilters, + CriteriaQueryTranslator.ROOT_SQL_ALIAS ); initFromWalker(walker); Example stack trace: could not execute query; nested exception is org.hibernate.exception.SQLGrammarException: could not execute query org.springframework.dao.InvalidDataAccessResourceUsageException: could not execute query; nested exception is org.hibernate.exception.SQLGrammarException: could not execute query at org.springframework.orm.hibernate3.SessionFactoryUtils.convertHibernateAccessException(SessionFactoryUtils.java:615) at org.springframework.orm.hibernate3.HibernateAccessor.convertHibernateAccessException(HibernateAccessor.java:412) at org.springframework.orm.hibernate3.HibernateTemplate.doExecute(HibernateTemplate.java:424) at org.springframework.orm.hibernate3.HibernateTemplate.executeWithNativeSession(HibernateTemplate.java:374) at org.springframework.orm.hibernate3.HibernateTemplate.findByCriteria(HibernateTemplate.java:1051) at org.springframework.orm.hibernate3.HibernateTemplate.findByCriteria(HibernateTemplate.java:1044) at com.onstation.service.PersistenceServiceImpl.findByCriteria(Unknown Source) at com.onstation.service.MailingServiceTest.shouldFailToFindStateConversions(MailingServiceTest.java:52) Caused by: org.hibernate.exception.SQLGrammarException: could not execute query at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:90) at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:66) at org.hibernate.loader.Loader.doList(Loader.java:2231) at org.hibernate.loader.Loader.listIgnoreQueryCache(Loader.java:2125) at org.hibernate.loader.Loader.list(Loader.java:2120) at org.hibernate.loader.criteria.CriteriaLoader.list(CriteriaLoader.java:118) at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1596) at org.hibernate.impl.CriteriaImpl.list(CriteriaImpl.java:306) at org.springframework.orm.hibernate3.HibernateTemplate$36.doInHibernate(HibernateTemplate.java:1061) at org.springframework.orm.hibernate3.HibernateTemplate.doExecute(HibernateTemplate.java:419) Caused by: java.sql.SQLException: ORA-00904: "THIS_"."SOURCE": invalid identifier at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:112) at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:331) at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:288) at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:745) at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:216) at oracle.jdbc.driver.T4CPreparedStatement.executeForDescribe(T4CPreparedStatement.java:810) at oracle.jdbc.driver.OracleStatement.executeMaybeDescribe(OracleStatement.java:1039) at oracle.jdbc.driver.T4CPreparedStatement.executeMaybeDescribe(T4CPreparedStatement.java:850) at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1134) at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3339) at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:3384) at org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:93) at org.apache.commons.dbcp.DelegatingPreparedStatement.executeQuery(DelegatingPreparedStatement.java:93) at org.hibernate.jdbc.AbstractBatcher.getResultSet(AbstractBatcher.java:208) at org.hibernate.loader.Loader.getResultSet(Loader.java:1808) at org.hibernate.loader.Loader.doQuery(Loader.java:697) at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:259) at org.hibernate.loader.Loader.doList(Loader.java:2228) Example query: Hibernate: select stateconve0_.FAILEDID as FAILEDID311_0_, stateconve0_.CREATED as CREATED311_0_, stateconve0_.LOG as LOG311_0_, stateconve0_.SOURCE as SOURCE311_0_ from STATECONVERTFAILED stateconve0_ where this_.SOURCE=? -- 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, 2 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-2826) IS [NOT] NULL checks with component values

by Steve Ebersole (JIRA)

IS [NOT] NULL checks with component values ------------------------------------------ Key: HHH-2826 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2826 Project: Hibernate3 Issue Type: Improvement Components: query-hql Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 3.2.6, 3.3 Currently the HQL translator attempts to render IS NULL and IS NOT NULL checks against a component using tuple syntax. Would be much better to instead "explode" these. For example, consider Person with a name property which is a component type of Name and the HQL: "from Person p where p.name is null" Currently, we'd end up with SQL like: "... from person p where (p.f_name, p.l_name) is null" but the exploded form would make much more sense here: "... from person p where ( p.f_name is null and p.l_name is null )" -- 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, 2 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-327) Capability to reuse IndexWriter instances across transactions

by Sanne Grinovero (JIRA)

Capability to reuse IndexWriter instances across transactions ------------------------------------------------------------- Key: HSEARCH-327 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-327 Project: Hibernate Search Issue Type: Improvement Reporter: Sanne Grinovero Fix For: 3.1.1 don't close the IndexWriter but reuse it for the work on the next transaction. It is needed that this can be disabled for some configurations: create a new configuration parameter. -- 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, 2 months

2
6
0 / 0

[Hibernate-JIRA] Created: (HBX-952) some way to generate DDL output

by Dan Allen (JIRA)

some way to generate DDL output ------------------------------- Key: HBX-952 URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-952 Project: Hibernate Tools Issue Type: Improvement Components: eclipse Environment: Eclipse 3.2.2 Hibernate Tools beta10 Reporter: Dan Allen After diligent searching, I could not find a way to get the generated DDL for the current hibernate.dialect from the Hibernate Console in Eclipse. Either this feature isn't available, or it needs to be better documented so that someone can locate its whereabouts. What I am looking for is an output that looks like CREATE TABLE foo ( id bigint(20) unsigned NOT NULL auto_increment ) and so on... I would think this would be an "exporter", but no dice. -- 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, 2 months

2
2
0 / 0

[Hibernate-JIRA] Created: (ANN-666) @SQLInsert does not work

by Alex (JIRA)

@SQLInsert does not work ------------------------- Key: ANN-666 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-666 Project: Hibernate Annotations Issue Type: Bug Affects Versions: 3.2.1 Environment: hibernate-3.2.3.ga.zip, MySQL client version: 5.0.22, MSSQL 2005 Reporter: Alex http://forum.hibernate.org/viewtopic.php?p=2367176#2367176 @Entity @Table(name = "CONTACTS") @SQLInsert(sql="INSERT INTO CONTACT(FIRST_NAME, LAST_NAME) VALUES(upper('aaa'),upper('bbb'))") public class Contact { // ... } I've tried the both - sql-query and stored procedure inside the @SQLInsert. But the both not work for me. It looks like the @SQLInsert annotation is just ignored for some reason. Usual "insert into CONTACT (FIRST_NAME, LAST_NAME) values (?, ?)" statement is generated despite of the @SQLInsert annotation. At the same time other annotations (@NamedNativeQuery, @Loader) work ok for the class. How to make it works, please? Thanks a lot in advance. Hibernate version: hibernate-3.2.3.ga.zip Mapping documents: sessionFactory = new AnnotationConfiguration() .addPackage("model") .addAnnotatedClass(Contact.class) .addAnnotatedClass(SpaceShip.class) .setProperty("hibernate.dialect", "org.hibernate.dialect.MySQLMyISAMDialect") .setProperty("hibernate.connection.url", "jdbc:mysql://localhost/test") .setProperty("hibernate.connection.driver_class", "com.mysql.jdbc.Driver") .setProperty("hibernate.connection.username", "usname") .setProperty("hibernate.connection.password", "1231123") .setProperty(Environment.HBM2DDL_AUTO, "update") .setProperty(Environment.SHOW_SQL, "true") .setProperty("hibernate.cache.provider_class", "org.hibernate.cache.NoCacheProvider") .buildSessionFactory(); Code between sessionFactory.openSession() and session.close(): session = HibernateUtil.getSession(); session.beginTransaction(); session.saveOrUpdate(newContact); session.getTransaction().commit(); Full stack trace of any exception that occurs: None Name and version of the database you are using: MySQL client version: 5.0.22 The generated SQL (show_sql=true): Hibernate: insert into CONTACT (FIRST_NAME, LAST_NAME) values (?, ?) -- 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, 2 months

8
14
0 / 0

[Hibernate-JIRA] Created: (ANN-594) Filters for MappedSuperClass

by Shawn Clowater (JIRA)

Filters for MappedSuperClass ---------------------------- Key: ANN-594 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-594 Project: Hibernate Annotations Issue Type: New Feature Components: binder Affects Versions: 3.3.0.ga Reporter: Shawn Clowater Priority: Minor Based on discussion from http://forum.hibernate.org/viewtopic.php?t=963539&start=0 Essentially, it would be nice to be able to define filters on a MappedSuperClass and have them 'trickle down' to the subclasses. (at the class level - not sure if property level filters are carried down right now). I see the MappedSuperClass as a means to define generic behaviour (common columns, etc) and I think it makes sense for the filters to play nicely as well. In addition, I don' t know if it is already a separate JIRA request, filters off of an Interface would be fantastic as well as our application is using filters heavily and are always looking at ways to reduce the amount of filter annotations that we have to spread around. Right now, we're either forced to copy filter annotations all over the place OR we've actually been a bit sneaky and have tapped into custom persisters to dynamically apply common filters. However, there is a separate issue based on the order that entity persisters are built. -- 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, 2 months

3
4
0 / 0

[Hibernate-JIRA] Created: (ANN-752) Setup continous integration

by Hardy Ferentschik (JIRA)

Setup continous integration --------------------------- Key: ANN-752 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-752 Project: Hibernate Annotations Issue Type: Task Reporter: Hardy Ferentschik Assignee: Hardy Ferentschik Priority: Minor Hibernate Annotations should be build continuously via Hudson. If possible each build should run the tests against multiple databases. -- 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, 2 months

1
1
0 / 0

[Hibernate-JIRA] Created: (ANN-753) Allow running tests against different databases by using a simple switch

by Hardy Ferentschik (JIRA)

Allow running tests against different databases by using a simple switch ------------------------------------------------------------------------ Key: ANN-753 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-753 Project: Hibernate Annotations Issue Type: Task Reporter: Hardy Ferentschik Assignee: Hardy Ferentschik Priority: Minor Currently you have to edit hibernate.properties to be able to run the tests against a different database. The settings of this file should be externalized and filters should be used to filter appropriate settings according to a property, eg 'ant clean junit -Dtargetdb=mysql'. To make this really useful one would also need a way within the test to skip it for a particular database. Some tests don't make sense against a certain target db. This might be a separate issue. Maybe one could switch to Junit 4 and add some custom annotation for enabling/disabling a test depending on the db. -- 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, 2 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HHH-2412) Hibernate 3 cannot be compiled under JDK 6

by Ahmet A. Akin (JIRA)

Hibernate 3 cannot be compiled under JDK 6 ------------------------------------------ Key: HHH-2412 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2412 Project: Hibernate3 Type: Task Components: core Versions: 3.2.1, 3.2.2 Environment: windows xp, JDK 6 Reporter: Ahmet A. Akin Hibernate code cannot be compiled under JDK 6. Problems and possible solutions: 1- org.hibernate.jdbc.ResultSetWrapper implements ResultSet. But in Java 6, there are big changes in Resultset interface, and maybe 20+ more methods needs to be implemented in the ResultSetWrapper class. i would suggest eliminating this wrapper class once and for all, because it is only used in one method (in ColumnNameCache, getIndexForColumnName method) and i dont think there is a justification for using that wrapper class. 2- org.hibernate.lob.SerializableBlob needs to implement new Blob interface methods: public void free() throws SQLException; public InputStream getBinaryStream(long pos, long length) throws SQLException But, if this class is publicly accesible or used by API's back compatibility issues needs to be checked. 3- Same as number 2, org.hibernate.lob.BlobImpl class needs to implement new Blob methods. 4- org.hibernate.lob.SerializableClob class needs to implent new Clob methods. 5- org.hibernate.lob.ClobImpl , same as 4. In fact, Java 6 has a lot of JDBC improvements, maybe a java6 special extra package can be created., but that is a whole different issue. -- 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, 2 months

8
18
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues April 2009