March 2010 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HBX-1144) Weird Column Length problem - new length value in annotation being ignored

by Duncan Kinnear (JIRA)

Weird Column Length problem - new length value in annotation being ignored -------------------------------------------------------------------------- Key: HBX-1144 URL: http://opensource.atlassian.com/projects/hibernate/browse/HBX-1144 Project: Hibernate Tools Issue Type: Bug Affects Versions: 3.2.0.GA Environment: Tar file was hibernate-3.2.6.ga.tar. Glassfish version 2.0 ur2. PostgreSQL version 8.x (various) Reporter: Duncan Kinnear We are using Hibernate as our persistence layer with NetBeans 6.7.1, EJB3, Glassfish and PostgreSQL. We have almost 200 tables defined as EJB entities. We use annotations on the entities to define the tables/columns. As we are still in an early testing phase, we regularly drop all the tables in the database and use the Hibernate auto schema update to recreate them. Recently we changed the length of a standard field that appears in many of our tables. The column is called ID_ORDER and is defined in the entities using the following code: @Column(name = "ID_ORDER", length = STANDARD_ID_ORDER_LENGTH, nullable = false) private String idOrder; where STANDARD_ID_ORDER_LENGTH is defined as a public static final int in the superclass of these tables. This length used to be 20, but we increased this to 50, recompiled all the affected classes, dropped all the tables and redeployed. Now, on 2 developer machines this change worked correctly, with the new tables having their ID_ORDER columns all length 50. However, on the other 2 developer machines, one table (called FEED_TYPE) gets recreated with the ID_ORDER column with length 20. This also occurs when we deploy the resulting EAR file to another server running Glassfish. We have tried all sorts of things on these machines to try and 'fix' this. We have removed the column completely, recreated the table and it is still there! We have explicitly set the length in the annotation of the column of this one table and the length is always ignored. We have renamed the existing column and deployed, but the new column is always length 20. We have renamed the table and then recreated it - still wrong. We have even dropped the entire database and recreated it, but the length of 20 remains! We are pulling our hair out on this one, it just doesn't make any sense. Where is hibernate 'caching' the length definition of this one column in one 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, 5 months

1
2
0 / 0

[Hibernate-JIRA] Created: (HHH-3787) org.hibernate.cfg.Configuration has non-Serializable member identifierGeneratorFactory

by Patrick Moore (JIRA)

org.hibernate.cfg.Configuration has non-Serializable member identifierGeneratorFactory -------------------------------------------------------------------------------------- Key: HHH-3787 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3787 Project: Hibernate Core Issue Type: Patch Components: core Affects Versions: 3.5 Environment: any Reporter: Patrick Moore Attachments: patch.txt //org.hibernate.cfg.Configuration (line 161): public class Configuration implements Serializable { // org.hibernate.cfg.Configuration (line 207): private DefaultIdentifierGeneratorFactory identifierGeneratorFactory; However DefaultIdentifierGeneratorFactory is not declared serializable. This patch makes DefaultIdentifierGeneratorFactory serializable. -- 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, 5 months

4
6
0 / 0

[Hibernate-JIRA] Created: (HV-292) Provide a constraint annotation @ScriptAssert

by Gunnar Morling (JIRA)

Provide a constraint annotation @ScriptAssert --------------------------------------------- Key: HV-292 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-292 Project: Hibernate Validator Issue Type: New Feature Components: validators Affects Versions: 4.1.0-Beta-1 Reporter: Gunnar Morling Assignee: Hardy Ferentschik Quite often the validation of one bean property depends on the value of another property of the same bean. In such case a custom class-level constraint and a corresponding validator have to be implemented. This effort can be reduced by providing a generic class-level constraint, which allows to evaluate arbitrary script expressions based on the annotated class as in the following example: @ScriptAssert(lang = "groovy", script = "_this.startDate.before(_this.endDate)") public class CalendarEvent { private Date startDate; private Date endDate; //... } The blog post http://musingsofaprogrammingaddict.blogspot.com/2009/08/script-annotation... describes, how such a constraint could be realized using the JSR 223 ("Scripting for the Java Platform") API. In alternative to solely rely on JSR 223 it should be investigated, whether a more general approach could be taken to enable the integration of scripting/expression languages, for which no JSR 223 binding exists (e.g. Spring EL). This could be realized by providing a SPI mechanism, which allows to plug-in additional script engine providers. -- 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, 5 months

2
8
0 / 0

[Hibernate-JIRA] Created: (HV-302) JAXB shouldn't be required when not using XML configuration

by Gunnar Morling (JIRA)

JAXB shouldn't be required when not using XML configuration ----------------------------------------------------------- Key: HV-302 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-302 Project: Hibernate Validator Issue Type: Improvement Components: engine Affects Versions: 4.1.0.Beta1 Reporter: Gunnar Morling Assignee: Hardy Ferentschik Fix For: 4.1.0 By calling Configuration#ignoreXmlConfiguration() any XML config files (validation.xml, mapping XML files) are ignored by HV. Nevertheless JAXB is required on the class path, as in any case the class org.hibernate.validator.xml.XmlMappingParser (which imports javax.xml.bind.*) is loaded, also if no XML mapping files are to be processed. XmlMappingParser should only be loaded, when at least one XML mapping exists. While this makes no difference when running on Java 6 (as JAXB is part of the Java runtime itself), this allows to use HV on Java 5 without adding JAXB (and its transitive dependencies) to the class path. -- 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, 5 months

2
6
0 / 0

[Hibernate-JIRA] Created: (HHH-4891) Using certain column names which mirror SQL function names causes "ambiguous column" SQL errors

by Manuel Dominguez Sarmiento (JIRA)

Using certain column names which mirror SQL function names causes "ambiguous column" SQL errors ----------------------------------------------------------------------------------------------- Key: HHH-4891 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4891 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.5.0-Beta-4, 3.5.0-Beta-3, 3.5.0-Beta-2 Environment: Error verified with Oracle, MySQL and H2 database engines. Reporter: Manuel Dominguez Sarmiento We have some columns names "floor" and "hash". This used to work fine until 3.5.0 Beta 2. This and later releases fail when a query involves a join with two tables and both each contain a column named either "floor" or "hash" with an "ambiguous column" error. 3.5.0 Beta 1 and previous releases work fine. Something must have changed in Beta 2 that is causing some kind of recognition of SQL function names, but I can't seem to pinpoint any issue related to this in the changelong. I'm pretty sure this would also happen with other column names such as "ceil", "abs", etc. which although they might be SQL function names they are not reserved keywords, and thus they are valid column names. -- 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, 5 months

5
6
0 / 0

[Hibernate-JIRA] Created: (HHH-4541) collection_valued_input_parameter not working in IN statement

by Farrukh Najmi (JIRA)

collection_valued_input_parameter not working in IN statement ------------------------------------------------------------- Key: HHH-4541 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4541 Project: Hibernate Core Issue Type: Bug Components: entity-manager Affects Versions: 3.5.0.Beta-1 Reporter: Farrukh Najmi 3.5.0-Beta1 of hibernate-entitymanager supports JPA 2.0. According to section 4.6.9 of the JPA 2.0 spec an IN statement can have a collection_valued_input_parameter: " in_expression ::= {state_field_path_expression | type_discriminator} [NOT] IN { ( in_item {, in_item}* ) | (subquery) | collection_valued_input_parameter } in_item ::= literal | single_valued_input_parameter " When I try the following query: SELECT DISTINCT Object(p) FROM org.freebxml.omar.jaxb.bindings.rim._4_0.PersonType p, org.freebxml.omar.jaxb.bindings.rim._4_0.AssociationType a WHERE a.sourceObject = :sourceObjectId AND p.id = a.targetObject AND a.type IN :typexxx with a List<String> value for collection_valued_input_parameter :typexxx I get the following unexpected error: Caused by: org.hibernate.hql.ast.QuerySyntaxException: unexpected token: : near line 1, column 226 [SELECT DISTINCT Object(p) FROM org.freebxml.omar.jaxb.bindings.rim._4_0.PersonType p, org.freebxml.omar.jaxb.bindings.rim._4_0.AssociationType a WHERE a.sourceObject = :sourceObjectId AND p.id = a.targetObject AND a.type IN :typexxx ] at org.hibernate.hql.ast.QuerySyntaxException.convert(QuerySyntaxException.java:54) at org.hibernate.hql.ast.QuerySyntaxException.convert(QuerySyntaxException.java:47) at org.hibernate.hql.ast.ErrorCounter.throwQueryException(ErrorCounter.java:82) at org.hibernate.hql.ast.QueryTranslatorImpl.parse(QueryTranslatorImpl.java:284) at org.hibernate.hql.ast.QueryTranslatorImpl.doCompile(QueryTranslatorImpl.java:182) at org.hibernate.hql.ast.QueryTranslatorImpl.compile(QueryTranslatorImpl.java:136) at org.hibernate.engine.query.HQLQueryPlan.<init>(HQLQueryPlan.java:101) at org.hibernate.engine.query.HQLQueryPlan.<init>(HQLQueryPlan.java:80) at org.hibernate.engine.query.QueryPlanCache.getHQLQueryPlan(QueryPlanCache.java:94) at org.hibernate.impl.AbstractSessionImpl.getHQLQueryPlan(AbstractSessionImpl.java:156) at org.hibernate.impl.AbstractSessionImpl.createQuery(AbstractSessionImpl.java:135) at org.hibernate.impl.SessionImpl.createQuery(SessionImpl.java:1585) at org.hibernate.ejb.AbstractEntityManagerImpl.createQuery(AbstractEntityManagerImpl.java:121) -- 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, 5 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-4922) Incorrect Parsing of IN-Clause in JPQL

by Pierce Wetter (JIRA)

Incorrect Parsing of IN-Clause in JPQL -------------------------------------- Key: HHH-4922 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4922 Project: Hibernate Core Issue Type: Bug Components: entity-manager Affects Versions: 3.5.0-Beta-4 Environment: 3.5.0-Beta-4, ALL Reporter: Pierce Wetter In the reference implementation, a query such as the following: select u from User u where u.loginName IN :logins will accept :logins as a parameter of Collection<String>. While: select u from User u where u.loginName IN (:login1) will accept :login1 as a String. For a collection, Hibernate insists on: select u from User u where u.loginName IN (:logins) and it throws an error on: select u from User u where u.loginName IN :logins But not only does this not match the reference implementation, but it precludes the use of: select u from User u where u.loginName IN (:login1. :login2, :login3) That is, is prevents the use of the IN clause with a hard coded set of String values. Test Case: It's pretty trivial. Both of these should be allowed: Query qTwoLogins = em.createQuery( "select u from User u where ou.loginId in (:login1, :login2)" ); Query qCollectionLogins = em.createQuery( "select u from User u where u.login in :logins" ); qTwoLogins.setParameter("login1","testuser1"); qTwoLogins.setParameter("login2","testuser2"); HashSet<String> list= new HashSet<String>(2); list.add("testuser1"); list.add("testuser2"); qCollectionLogins.setParameter("logins",list); -- 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, 5 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-5044) Having @MappedSuperClass inbetween an abstract-class with InheritanceType.JOINED and an Entity fails

by Andreas Joseph Krogh (JIRA)

Having @MappedSuperClass inbetween an abstract-class with InheritanceType.JOINED and an Entity fails ---------------------------------------------------------------------------------------------------- Key: HHH-5044 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5044 Project: Hibernate Core Issue Type: Bug Affects Versions: 3.5.0-CR-2 Environment: JDK-1.6 SE, Spring-3.0.1 Reporter: Andreas Joseph Krogh Attachments: jpa2failure-java-working.jar, jpa2failure-java.jar Hi. Attached are 2 small testcases (in Maven2) which contain one case showing the failure and one working case. The working case has removed the inbetween @MappedSuperClass. What fails is retrieving an entity using the generic "origoEntityRepository", which returns arbitrary entities extending the AbstractEntityObject. This works fine in Hibernate-3.3.2/JPA1 btw. -- 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, 5 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-4921) 3.5 (JPA 2) doesn't allow order by alias

by Tomasz Bech (JIRA)

3.5 (JPA 2) doesn't allow order by alias ---------------------------------------- Key: HHH-4921 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4921 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.5.0-CR-1 Reporter: Tomasz Bech Attachments: JPAQLComplianceTest.java I've created following test case in JPAQLComplianceTest.java: public void testOrderByAlias() { Session s = openSession(); s.createQuery( "select c.name as myname FROM Item c ORDER BY myname" ).list(); s.close(); } and it fails: Caused by: java.sql.SQLException: Column not found: MYNAME in statement [select item0_.NAME as col_0_0_ from EJB3_ITEM item0_ order by myname] at org.hsqldb.jdbc.Util.throwError(Unknown Source) at org.hsqldb.jdbc.jdbcPreparedStatement.<init>(Unknown Source) at org.hsqldb.jdbc.jdbcConnection.prepareStatement(Unknown Source) at org.hibernate.jdbc.AbstractBatcher.getPreparedStatement(AbstractBatcher.java:534) at org.hibernate.jdbc.AbstractBatcher.getPreparedStatement(AbstractBatcher.java:452) at org.hibernate.jdbc.AbstractBatcher.prepareQueryStatement(AbstractBatcher.java:161) at org.hibernate.loader.Loader.prepareQueryStatement(Loader.java:1598) at org.hibernate.loader.Loader.doQuery(Loader.java:718) at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:271) at org.hibernate.loader.Loader.doList(Loader.java:2273) ... 30 more Spec says in '4.9 ORDER BY Clause' that 'order by alias' is supported by JPA 2. -- 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, 5 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-4952) jDocBook injections no longer working on core reference manual

by Steve Ebersole (JIRA)

jDocBook injections no longer working on core reference manual -------------------------------------------------------------- Key: HHH-4952 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4952 Project: Hibernate Core Issue Type: Bug Components: core, documentation Affects Versions: 3.5.0-CR-2 Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 3.5.0.Next This has to be related to the merging back of the Red Hat doc team work on the docs. My guess specifically is their use of .ent files for all DTD entities. -- 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, 5 months

1
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues March 2010