March 2011 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-5968) Deprecate nullSafeGet()/nullSafeSet() methods with no SessionImplementor argument from UserType and AbstractSingleColumnStandardBasicType

by Gail Badner (JIRA)

Deprecate nullSafeGet()/nullSafeSet() methods with no SessionImplementor argument from UserType and AbstractSingleColumnStandardBasicType ----------------------------------------------------------------------------------------------------------------------------------------- Key: HHH-5968 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5968 Project: Hibernate Core Issue Type: Deprecation Components: core Reporter: Gail Badner Assignee: Gail Badner Fix For: 3.6.2 UserType.nullSafeGet() and nullSafeSet() methods will be deprecated because they do not take a SessionImplementor argument: public Object nullSafeGet(ResultSet rs, String[] names, Object owner) public void nullSafeSet(PreparedStatement st, Object value, int index) They will be replaced by methods taking a SessionImplementor argument in Hibernate 4. These new methods will not be added to UserType because doing so would break everyone's UserType implementation. In AbstractSingleColumnStandardBasicType, the following methods will be deprecated: public T nullSafeGet(ResultSet rs, String name) public Object get(ResultSet rs, String name) public void nullSafeSet(PreparedStatement st, T value, int index) public void set(PreparedStatement st, T value, int index) These methods should have been deprecated in AbstractSingleColumnStandardBasicType when their super methods in SingleColumnType were deprecated (the deprecation did not come across in Javadoc generated by {@inheritDoc}). The following methods should be used instead: AbstractSingleColumnStandardBasicType.nullSafeSet(PreparedStatement st, Object value, int index, boolean[] settable, SessionImplementor session) AbstractStandardBasicType.nullSafeGet(ResultSet rs, String name, SessionImplementor session, Object owner) -- 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

13 years, 3 months

5
9
0 / 0

[Hibernate-JIRA] Created: (HHH-3836) composite-element with null columns in map is ignored

by Benoit Goudreault-Emond (JIRA)

composite-element with null columns in map is ignored ----------------------------------------------------- Key: HHH-3836 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3836 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.3.0.SP1 Environment: 3.3.0 SP1, noticed with Oracle and H2 but probably happens with all databases Reporter: Benoit Goudreault-Emond Attachments: patate.zip When a composite element with all properties set to NULL is inserted in a map of the said composite element, the data gets inserted to the database but is never retreived when reloading the entity. For instance, with an entity @Entity public class TestEntity { @Id private int id; @CollectionOfElements private Map<String, AccessPeriod> roleAccesses = new HashMap<String, AccessPeriod>(); // boilerplate getters/setters/etc omitted } And AccessPeriod being @Embeddable public class AccessPeriod { public Date startDate; public Date endDate; } If you insert in the map an AccessPeriod with both startDate and endDate set to null and persist the TestEntity, an entry is inserted in the auxiliary table, but when getting the TestEntity back, the map is empty. You get the same problem with a mapping file. This used to work in Hibernate 2.1--I found this out while porting some code to 3.3. See the attached example. You'll need to include Hibernate and h2 (com.h2database:h2 1.0.20061217) on your classpath to run it with the given jdbc.properties, but feel free to change 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

13 years, 4 months

5
6
0 / 0

[Hibernate-JIRA] Created: (HHH-5801) ColumnNameCache.columnNameToIndexCache map should be synchronized

by Ivan Popov (JIRA)

ColumnNameCache.columnNameToIndexCache map should be synchronized ----------------------------------------------------------------- Key: HHH-5801 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5801 Project: Hibernate Core Issue Type: Bug Affects Versions: 3.2.7 Environment: AIX, IMB J9 jvm Reporter: Ivan Popov When I activate the result set wapper, hibernate.jdbc.wrap_result_sets=true, I can have a stacktrace such as : ####<Dec 15, 2010 8:44:27 PM CET> <Error> <WebLogicServer> <efa-bench> <decalog_server> <[ACTIVE] ExecuteThread: '29' for queue: 'weblogic.kernel.Default (self-tuning)'> <<WLS Kernel>> <> <> <1292442267345> <BEA-000337> <[STUCK] ExecuteThread: '21' for queue: 'weblogic.kernel.Default (self-tuning)' has been busy for "602" seconds working on the request "weblogic.work.SelfTuningWorkManagerImpl$WorkAdapterImpl@73907390", which is more than the configured time (StuckThreadMaxTime) of "600" seconds. Stack trace: java.util.HashMap.findNonNullKeyEntry(HashMap.java:526) java.util.HashMap.getEntry(HashMap.java:510) java.util.HashMap.get(HashMap.java:496) org.hibernate.jdbc.ColumnNameCache.getIndexForColumnName(ColumnNameCache.java:52) org.hibernate.jdbc.ResultSetWrapper.findColumn(ResultSetWrapper.java:84) org.hibernate.jdbc.ResultSetWrapper.getString(ResultSetWrapper.java:248) org.hibernate.type.StringType.get(StringType.java:18) org.hibernate.type.NullableType.nullSafeGet(NullableType.java:163) org.hibernate.type.NullableType.nullSafeGet(NullableType.java:154) org.hibernate.type.AbstractType.hydrate(AbstractType.java:81) org.hibernate.persister.entity.AbstractEntityPersister.hydrate(AbstractEntityPersister.java:2091) org.hibernate.loader.Loader.loadFromResultSet(Loader.java:1380) org.hibernate.loader.Loader.instanceNotYetLoaded(Loader.java:1308) org.hibernate.loader.Loader.getRow(Loader.java:1206) org.hibernate.loader.Loader.getRowFromResultSet(Loader.java:580) org.hibernate.loader.Loader.doQuery(Loader.java:701) org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:236) org.hibernate.loader.Loader.loadCollection(Loader.java:1998) org.hibernate.loader.collection.CollectionLoader.initialize(CollectionLoader.java:36) org.hibernate.persister.collection.AbstractCollectionPersister.initialize(AbstractCollectionPersister.java:565) org.hibernate.event.def.DefaultInitializeCollectionEventListener.onInitializeCollection(DefaultInitializeCollectionEventListener.java:63) org.hibernate.impl.SessionImpl.initializeCollection(SessionImpl.java:1717) org.hibernate.collection.AbstractPersistentCollection.initialize(AbstractPersistentCollection.java:344) org.hibernate.collection.AbstractPersistentCollection.read(AbstractPersistentCollection.java:86) org.hibernate.collection.AbstractPersistentCollection.readSize(AbstractPersistentCollection.java:109) org.hibernate.collection.PersistentSet.size(PersistentSet.java:139) I think that columnNameToIndexCache map should be synchronized. I got the exception with 3.2.7 but I had a look at the latest version and the bug is still there. -- 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

13 years, 4 months

3
3
0 / 0

[Hibernate-JIRA] Created: (HCANN-18) Make sure that the build enforces JDK 5 compilation just like Core does today

by Emmanuel Bernard (JIRA)

Make sure that the build enforces JDK 5 compilation just like Core does today ----------------------------------------------------------------------------- Key: HCANN-18 URL: http://opensource.atlassian.com/projects/hibernate/browse/HCANN-18 Project: Hibernate Commons Annotations Issue Type: Task Affects Versions: 3.2.0 Reporter: Emmanuel Bernard Assignee: Hardy Ferentschik -- 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

13 years, 4 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-3318) Allow omitting varchar limit by default in PostgreSQL

by Luke Maurer (JIRA)

Allow omitting varchar limit by default in PostgreSQL ----------------------------------------------------- Key: HHH-3318 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3318 Project: Hibernate3 Issue Type: New Feature Components: core Environment: Hibernate 3.2.6, PostgreSQL 8.3.1 Reporter: Luke Maurer Priority: Minor Essentially, what I'd like is for a String without a given maximum length be mapped as a varchar or text rather than a varchar(255) as is now the case. The maximum doesn't do anything to improve performance or storage efficiency in PostgreSQL, so varchar(255) merely imposes an arbitrary constraint. It would be more idiomatic to use varchar where no limit is given, leaving varchar(n) for cases where the length is limited as a business rule rather than an implementation detail. (Naturally, one can always use @Lob where it's actually *important* that the column be a varchar or text. So this is definitely 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

13 years, 4 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-710) Add option to index fields using ANALYZED_NO_NORMS

by Sanne Grinovero (JIRA)

Add option to index fields using ANALYZED_NO_NORMS -------------------------------------------------- Key: HSEARCH-710 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-710 Project: Hibernate Search Issue Type: New Feature Reporter: Sanne Grinovero Assignee: Sanne Grinovero Fix For: 3.4.0.Beta1 It seems it's currently not possible to use the indexing option org.apache.lucene.document.Field.Index.ANALYZED_NO_NORMS (workaround: use a custom fieldbridge) -- 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

13 years, 4 months

2
7
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-711) Review of org.hibernate.search.annotations.Index API (token names, parameter composition)

by Sanne Grinovero (JIRA)

Review of org.hibernate.search.annotations.Index API (token names, parameter composition) ----------------------------------------------------------------------------------------- Key: HSEARCH-711 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-711 Project: Hibernate Search Issue Type: Deprecation Reporter: Sanne Grinovero Fix For: 4.0 We're having Enum values labeled NO,TOKENIZED,UN_TOKENIZED,NO_NORMS,.. while Lucene changed these names to more suited "analyzed", "not_analyzed", etc. Also I think it would be great to use an array of parameters instead of an enum listing all options, or maybe split the option in two: @Field({ANALYZE,NO_NORMS}) or @Field(analyze=YES,norms=No) We should at least deprecate current names and use the more appropriate terms. -- 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

13 years, 4 months

2
14
0 / 0

[Hibernate-JIRA] Created: (HHH-5645) Criteria.createAlias with specified criterion results in wrong parameters passed into SQL statement

by Fekete Kamosh (JIRA)

Criteria.createAlias with specified criterion results in wrong parameters passed into SQL statement --------------------------------------------------------------------------------------------------- Key: HHH-5645 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5645 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.5.6 Environment: Windows XP SP2, Hibernate 3.5.6, JRE 1.6.0_14, PostgreSQL (tested also with Sybase ASE) Reporter: Fekete Kamosh Attachments: aliases_test.zip Suppose to have tables A, B, C. Relationships: A(one)=>B(many); B(one)=>C(many) Table A is used as main entity. For tables B and C lets *establish aliases* using method _public Criteria createAlias(String associationPath, String alias, int joinType, *Criterion withClause*) throws HibernateException;_ Each created alias has addition Criterion to force Hibernate generate clause _"on column = column and (other_criterion_condition)"._ If aliases are created in *order B, C* everything is OK: Resulting SQL: _SELECT this_.table_a_character AS y0_ FROM table_a this_ LEFT OUTER JOIN table_b tablebalia1_ ON this_.table_a_id = tablebalia1_.table_a_id AND ( tablebalia1_.table_b_date = ? ) LEFT OUTER JOIN table_c tablecalia2_ ON tablebalia1_.table_b_id = tablecalia2_.table_b_id AND ( tablecalia2_.table_c_boolean = ? ) WHERE this_.table_a_character = ?_ Passed parameters: *[Sun Oct 10 22:09:31 CEST 2010, false, c]* But if aliases are created in *order C, B error occurs* as resulting SQL remains the same as already shown, but Passed parameters are: *[false, Sun Oct 10 22:12:13 CEST 2010, c]* which causes SQL exception, because there are passed *parameters in wrong order to SQL statement*: 43843 [main] WARN org.hibernate.util.JDBCExceptionReporter - SQL Error: 0, SQLState: 42883 43843 [main] ERROR org.hibernate.util.JDBCExceptionReporter - ERROR: operator does not exist: date = boolean *Test example* (database tables, entities, hibernate.cfg and test file) *attached.* -- 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

13 years, 4 months

2
6
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-620) Archetype does not deploy on JBoss Nexus repository due to missing pom fields

by Hardy Ferentschik (JIRA)

Archetype does not deploy on JBoss Nexus repository due to missing pom fields ----------------------------------------------------------------------------- Key: HSEARCH-620 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-620 Project: Hibernate Search Issue Type: Bug Components: build Affects Versions: 3.3.0.Beta3 Reporter: Hardy Ferentschik Fix For: 3.3.0.CR1 The quickstart archetype does not deploy on the Nexus server, because the test pom is missing several project information fields. For the purpose of the archetype this is not a problem, but it seems that Nexus is configured to verify certain pom fields. Using the current configuration I was not able to close the staging repository (see screenshot). As a solution we can add dummy fields for the required nodes. We should also talk to Paul - do this rules always makes sense? -- 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

13 years, 4 months

4
22
0 / 0

[Hibernate-JIRA] Created: (HHH-3244) Implement support NVARCHAR type

by Sergey Derugo (JIRA)

Implement support NVARCHAR type -------------------------------- Key: HHH-3244 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3244 Project: Hibernate3 Issue Type: New Feature Components: core Environment: al Reporter: Sergey Derugo JDBC 4.0 allows supports NVARCHAR type, but Hibernate doesn't handle it. Please implement support for NVarchar -- 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

13 years, 4 months

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 2011