April 2008 - hibernate-issues - Jboss List Archives

[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

11 years, 11 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

11 years, 11 months

3
11
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

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

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

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

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-2548) when "order by" a composit object, which may be null, the result list returns only when the composit objcts not null

by Yu Deng (JIRA)

when "order by" a composit object, which may be null, the result list returns only when the composit objcts not null -------------------------------------------------------------------------------------------------------------------- Key: HHH-2548 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2548 Project: Hibernate3 Issue Type: Bug Affects Versions: 3.2.3 Environment: tomcat 5.5, eclipse3.2, jre1.5, postgreSQL8.1, hibernate3 and hibernate3.2 Reporter: Yu Deng Priority: Critical <hibernate-mapping package="com.grapevinecs.ams.domain.perbranch.inv"> <class name="InvItem"> <id name="id" column="id"> <generator class="hilo"/> </id> ... <many-to-one name="transferredDetails"/>  .... </class> (another mapping file) </hibernate-mapping>> <hibernate-mapping package="com.grapevinecs.ams.domain.perbranch.inv"> <class name="InvTransferDetails" > <id name="id" column="id"> <generator class="hilo"/> </id> <property name="returnedToICBC" type="com.grapevinecs.ams.dao.BooleanInteger" not-null="true"/> ... </class> </hibernate-mapping> Probelm: 1) The result returns 3000 records ---- select count(*) from InvItem c where upper(c.invType) LIKE '%D%' and c.invSeries.closed = '0' and c.branch =60551 order by c.transferredDetails.returnedToICBC asc, c.stamp asc,c.invNmbr asc 2) result List return size 0 by this query --- from InvItem c where upper(c.invType) LIKE '%D%' and c.invSeries.closed = '0' and c.branch =60551 order by c.transferredDetails.returnedToICBC asc, c.stamp asc,c.invNmbr asc 1) is correct but 2) is not correct. only when transferredDetails in InvItem not null be returned. in case 2), I have no transferredDetails not null. after I excuted the query 2), even I remove "c.transferredDetails.returnedToICBC asc", the result is still return nothing. -- 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, 1 month

3
2
0 / 0

[Hibernate-JIRA] Created: (ANN-640) use property names defined in CompositeUserType as default column names

by Michael Newcomb (JIRA)

use property names defined in CompositeUserType as default column names ----------------------------------------------------------------------- Key: ANN-640 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-640 Project: Hibernate Annotations Issue Type: New Feature Affects Versions: 3.3.0.ga Reporter: Michael Newcomb Priority: Minor Consider: public class LongitudeLatitude { protected double longitude; protected double latitude; } public class LongitudeLatitudeCompositeUserType implements CompositeUserType { public String[] getPropertyNames() { return new String[] { "longitude", "latitude" }; } public Type[] getPropertyTypes() { return new Type[] { Hibernate.DOUBLE, Hibernate.DOUBLE }; } ... } @Entity public class Test { @Basic(optional = false) @Type(type = "foo.bar.LongitudeLatitudeCompositeUserType") @Columns(columns = { @Column(name = "location_longitude"), @Column(name = "location_latitude") }) protected LongitudeLatitude location; } Why does the developer need to specify each column? I'd really rather let the CompositeUserType take care of that for me. Now, I have to tie the @Columns to the # of properties in my CompositeUserType AND the order in which they are defined? This seems to defeat the purpose of having a class (CompositeUserType) to tell Hibernate how to store it. Couldn't Hibernate prepend the property name 'location' and '_' to the front of each property name in the CompositeUserType? Perhaps (more than likely) I'm doing something wrong, but I get a failure if I do not specify the columns. Thanks, Michael -- 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, 1 month

6
16
0 / 0

[Hibernate-JIRA] Created: (HHH-2968) SimpleExpression.getTypedValues NullPointerException when ignoreCase and value==null

by Martijn Brinkers (JIRA)

SimpleExpression.getTypedValues NullPointerException when ignoreCase and value==null ------------------------------------------------------------------------------------ Key: HHH-2968 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2968 Project: Hibernate3 Issue Type: Bug Affects Versions: 3.2.5 Reporter: Martijn Brinkers If ignoreCase is true and value is null a NullPointerException is thrown because toString() is called without checking for null. public TypedValue[] getTypedValues(Criteria criteria, CriteriaQuery criteriaQuery) throws HibernateException { Object icvalue = ignoreCase ? value.toString().toLowerCase() : value; return new TypedValue[] { criteriaQuery.getTypedValue(criteria, propertyName, icvalue) }; } -- 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, 1 month

4
3
0 / 0

[Hibernate-JIRA] Created: (HHH-2971) AbstractFlushingEventListener catches, logs and re-throws HibernateException in performExecutions generating noisy logs

by craig mcmillan (JIRA)

AbstractFlushingEventListener catches, logs and re-throws HibernateException in performExecutions generating noisy logs ----------------------------------------------------------------------------------------------------------------------- Key: HHH-2971 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2971 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.5 Environment: v3.2.5 Reporter: craig mcmillan Priority: Minor AbstractFlushingEventListener catches HibernateException, logs an error, and re-throws the same HibernateException... so the Exception gets logged twice, or worse [ in the case i'm looking at, an offline locker ], an expected Exception [ConstraingViolationException] is caught and discarded, but an error is still logged -- 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, 1 month

13
15
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues April 2008