January 2009 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-2828) criteria search by class throws org.hibernate.QueryException: Unsupported discriminator type null when mapping exists for this class

by jo desmet (JIRA)

criteria search by class throws org.hibernate.QueryException: Unsupported discriminator type null when mapping exists for this class ------------------------------------------------------------------------------------------------------------------------------------- Key: HHH-2828 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2828 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.5 Environment: hibernate 3.2.5, oracle 10g Reporter: jo desmet Attachments: src.zip when making a criteria based on a property of type class the query succeeds if this class is not mapped, the query building fails when this class is mapped within hibernate and has no discriminator e.g. code : Criteria l = session.createCriteria(SearchClass.class); l.add(Restrictions.eq("type", ClassWithNoMapping.class)); // SUCCESS java.util.List result = l.list(); l = session.createCriteria(SearchClass.class); l.add(Restrictions.eq("type", ClassWithMapping.class)); // EXCEPTION result = l.list(); exception is Hibernate: select this_.ID as ID0_0_, this_.name as name0_0_, this_.type as type0_0_ from SEARCHCLASS this_ where this_.type=? org.hibernate.QueryException: Unsupported discriminator type null at org.hibernate.loader.criteria.CriteriaQueryTranslator.getTypedValue(CriteriaQueryTranslator.java:499) at org.hibernate.criterion.SimpleExpression.getTypedValues(SimpleExpression.java:71) at org.hibernate.loader.criteria.CriteriaQueryTranslator.getQueryParameters(CriteriaQueryTranslator.java:251) at org.hibernate.loader.criteria.CriteriaLoader.list(CriteriaLoader.java:95) at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1569) at org.hibernate.impl.CriteriaImpl.list(CriteriaImpl.java:283) at Test.list(Test.java:40) at Test.main(Test.java:27) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.intellij.rt.execution.application.AppMain.main(AppMain.java:90) classes are attached, tables should exists but no data is required. Please also provide workaround on short term if possible -- 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

12 years, 7 months

4
4
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-188) Add an option to use JMS in a JTA tx (rather than the post TX work done right now)

by Emmanuel Bernard (JIRA)

Add an option to use JMS in a JTA tx (rather than the post TX work done right now) ---------------------------------------------------------------------------------- Key: HSEARCH-188 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-188 Project: Hibernate Search Issue Type: New Feature Components: engine Reporter: Emmanuel Bernard Priority: Minor I think the main problem is ordering the hibernate flush and the JMS process. But I think the current PostTransactionWorkQueueSynchronization.beforeCompletion() suffers from the problem already. -- 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

12 years, 7 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-5) Only index an entity when it's index properties have physically changed

by Emmanuel Bernard (JIRA)

Only index an entity when it's index properties have physically changed ----------------------------------------------------------------------- Key: HSEARCH-5 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-5 Project: Hibernate Search Type: New Feature Components: engine Reporter: Emmanuel Bernard Priority: Minor -- 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

12 years, 7 months

3
11
0 / 0

[Hibernate-JIRA] Created: (HHH-3718) call to id getter initializes proxy when using AccessType( "field" )

by Paul Lorenz (JIRA)

call to id getter initializes proxy when using AccessType( "field" ) -------------------------------------------------------------------- Key: HHH-3718 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3718 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.1 Environment: hibernate 3.3.1, hibernate annotations 3.4.0, running on windows, linux and solaris, using sybase 15 Reporter: Paul Lorenz Calling getter for id when using AccessType( "field" ) causes proxy initialization. In org.hibernate.proxy.proxy.pojo.BasicLazyInitializer there is the code else if ( isUninitialized() && method.equals(getIdentifierMethod) ) { return getIdentifier(); } However, when using field access, the getIdentifierMethod will be null. I fixed this for us by changing DirectPropertyAccessor by adding a Method attribute to the DirectGetter inner class, and looking up the appropriate getter in the constructor. As far as I can tell, getMethod is only used in two places. In the above case, to the get the identity getter and in PojoComponentTupilizer.isMethodOf. This doesn't seem to break anything. I don't know if this is a clean solution, seems a little hacky to me, however, it would be great if the issue could be fixed somehow. public static final class DirectGetter implements Getter { private final transient Field field; private final Class clazz; private final String name; private Method method; DirectGetter(Field field, Class clazz, String name) { this.field = field; this.clazz = clazz; this.name = name; try { BeanInfo beanInfo = Introspector.getBeanInfo( clazz ); PropertyDescriptor[] pdArray = beanInfo.getPropertyDescriptors(); if ( pdArray != null ) { for (PropertyDescriptor pd : pdArray ) { if ( pd.getName().equals( name ) ) { this.method = pd.getReadMethod(); } } } } catch ( Exception e ) { // ignore } } public Object get(Object target) throws HibernateException { try { return field.get(target); } catch (Exception e) { throw new PropertyAccessException(e, "could not get a field value by reflection", false, clazz, name); } } public Object getForInsert(Object target, Map mergeMap, SessionImplementor session) { return get( target ); } public Method getMethod() { return method; } public String getMethodName() { return method == null ? null : method.getName(); } public Class getReturnType() { return field.getType(); } Object readResolve() { return new DirectGetter( getField(clazz, name), clazz, name ); } public String toString() { return "DirectGetter(" + clazz.getName() + '.' + name + ')'; } } -- 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

12 years, 8 months

10
18
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-295) Generate the "right" FilterKey instance even on parameterized filters

by Emmanuel Bernard (JIRA)

Generate the "right" FilterKey instance even on parameterized filters --------------------------------------------------------------------- Key: HSEARCH-295 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-295 Project: Hibernate Search Issue Type: New Feature Components: engine Reporter: Emmanuel Bernard Priority: Minor Rules around object equality are the most tricky. Not sure we can do a good job at it. -- 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

12 years, 8 months

2
4
0 / 0

[Hibernate-JIRA] Created: (HHH-2614) Blob Length Set to 255 By Default With Derby DB

by Sean Sylvis (JIRA)

Blob Length Set to 255 By Default With Derby DB ----------------------------------------------- Key: HHH-2614 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2614 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.3 Environment: Apache Derby 10.2.2, Java 1.6.0 Reporter: Sean Sylvis When the (Hibernate) type "blob" is used in an object mapping file and a length is not specified, Hibernate converts this type as "blob (255)" to the Apache Derby database table definition. (This seems to be the same as the conversion behavior of a Java String to "varchar (255).") The same behavior results when using a CustomType that returns a Java SQL Types.BLOB. This is not the behavior I expected. Hibernate converts the same type as simply "blob" (which has a maximum length of 65535 bytes when no length is specified) when using MySQL version 5.0 (http://dev.mysql.com/doc/refman/5.0/en/storage-requirements.html). Furthermore, the Derby specification (http://db.apache.org/derby/docs/10.2/ref/rrefblob.html) states that a blob type without a length value will default to a length of 2M-1 bytes. I could not find a length specification for the Java SQL Blob type (http://java.sun.com/javase/6/docs/api/), but the current default length does seem to conform to other Hibernate type standards. That is, if a length is not specified, the length defaults to the maximum length defined for that type by 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

12 years, 8 months

9
13
0 / 0

[Hibernate-JIRA] Created: (HHH-3240) In Derby field type 'text' is converted to CLOB(255)

by Aleksander Rozman (JIRA)

In Derby field type 'text' is converted to CLOB(255) ---------------------------------------------------- Key: HHH-3240 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3240 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.1 Environment: Hibernate 3.1, Derby 10.3.2.1 Reporter: Aleksander Rozman Priority: Blocker When using type 'text' this is incorectly converted to CLOB(255). Derby has several long var char types which could be used instead, but instead it's defaulted to clob(255). I have taken a look at source from 3.1 and 3.2.6 (latest) and this code is still the same... I think that just little fix in DerbyDialect would be enough... I would try this myself but I am currently lacking time and resources. I hope this will be taken care of as soon as it gets... -- 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

12 years, 8 months

7
25
0 / 0

[Hibernate-JIRA] Created: (ANN-728) @NaturalId doesn't work with @Embeddable/@Embedded

by Kenny MacLeod (JIRA)

@NaturalId doesn't work with @Embeddable/@Embedded -------------------------------------------------- Key: ANN-728 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-728 Project: Hibernate Annotations Issue Type: Bug Affects Versions: 3.3.1.GA Reporter: Kenny MacLeod Attachments: BugTestCase.java If I try to annotate an @Entity's field with @NaturalId, and that field happens to be @Embedded or @Embeddable, then hibernate barfs with org.hibernate.MappingException: Unable to find logical column name from physical name component in table BugTestCase$MyEntity at org.hibernate.cfg.Mappings.getLogicalColumnName(Mappings.java:514) at org.hibernate.cfg.IndexOrUniqueKeySecondPass.doSecondPass(IndexOrUniqueKeySecondPass.java:61) at org.hibernate.cfg.Configuration.secondPassCompile(Configuration.java:1136) at org.hibernate.cfg.AnnotationConfiguration.secondPassCompile(AnnotationConfiguration.java:324) at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1292) at org.hibernate.cfg.AnnotationConfiguration.buildSessionFactory(AnnotationConfiguration.java:859) See attached unit test as a demonstration. Surely this is not an exotic scenario? Tested with Hibernate Core 3.2.6-GA -- 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

12 years, 8 months

3
2
0 / 0

[Hibernate-JIRA] Created: (HHH-2085) org.hibernate.event.def.DefaultLoadEventListener logs exception at info level

by Don Smith (JIRA)

org.hibernate.event.def.DefaultLoadEventListener logs exception at info level ----------------------------------------------------------------------------- Key: HHH-2085 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2085 Project: Hibernate3 Type: Bug Components: core Versions: 3.2.0.cr2 Environment: Hibernate 3.2.0.cr2, MySQL 4.0.18 Reporter: Don Smith Priority: Minor Prior to schema generation, accessing a persistent object throws an exception, as expected. The org.hibernate.event.def.DefaultLoadEventListener logs the exception at the info level, which just adds noise to the application console, and prevents application exception handling (in my case it's valid if the table doesn't exist, so I just want to catch the exception and continue). This log statement should be removed, or moved to a debug or trace level, so it won't show up in normal execution. Code, from line 94 of org.hibernate.event.def.DefaultLoadEventListener: catch(HibernateException e) { log.info("Error performing load command", e); throw e; } -- 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

12 years, 8 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-3307) HQL query translation in real SQL ignores the dialect class

by Thomas Schilf (JIRA)

HQL query translation in real SQL ignores the dialect class ----------------------------------------------------------- Key: HHH-3307 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3307 Project: Hibernate3 Issue Type: Bug Components: query-hql Affects Versions: 3.2.6 Environment: dialect file with special JoinFragment and a "transformSelectString" step Reporter: Thomas Schilf We're using a special dialect class for a database. In the dialect is defined a own JoinFragment and a "transformSelectString" step. All workes fine by loading objects over a Criteria class. The generated SQL string is wrong by using named queries (HQL). The SQL string is in normal ANSI-SQL. The SqlGenerator and QueryTranslatorImpl classes from hibernate don't use the dialect class. -- 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

12 years, 8 months

2
3
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues January 2009