February 2012 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HHH-7060) Add support for mode that causes SQL Server dialect to treat application as semantically authoritative in regards to Java types and their value ranges

by John Verhaeg (JIRA)

Add support for mode that causes SQL Server dialect to treat application as semantically authoritative in regards to Java types and their value ranges ------------------------------------------------------------------------------------------------------------------------------------------------------ Key: HHH-7060 URL: https://hibernate.onjira.com/browse/HHH-7060 Project: Hibernate ORM Issue Type: Bug Components: core Affects Versions: 4.1.0 Reporter: John Verhaeg Assignee: John Verhaeg In particular, there is a disconnect between the value ranges supported by bytes in Java vs. SQL Server: Java byte values are 1 byte, unsigned, while SQL Server values are 0-255. Previously, negative byte values stored in the Java model would be treated as unsigned bytes by the driver, allowing the reading and writing of such values to "work" from the standpoint of the application, but also resulting in a completely different positive value being stored within the database. HHH-6815 addressed this disconnect from the standpoint of ensuring values set in the Java model were kept semantically in tact within the database and forcing the use of SMALL_INT columns instead of TINY_INT columns for byte values. However, this solution assumes it's important that the database values exactly match what's in the Java model. It also does not allow for existing databases with existing TINY_INT columns, which end up experiencing exceptions when negative byte values are persisted and later retrieved. The proposed solution is to offer some type of mode that can be set by the user to indicate the Java model should be treated as authoritative wrt data values, which would cause Hibernate to perform as it did in previous releases. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

2
3
0 / 0

[Hibernate-JIRA] Created: (HHH-7063) Many-to-one attribute type not resolved using HBM XML unless specifically defined

by Gail Badner (JIRA)

Many-to-one attribute type not resolved using HBM XML unless specifically defined --------------------------------------------------------------------------------- Key: HHH-7063 URL: https://hibernate.onjira.com/browse/HHH-7063 Project: Hibernate ORM Issue Type: Bug Components: metamodel Reporter: Gail Badner Assignee: Gail Badner Fix For: 5.0.0 This causes BasicHbmBindingTests.testEntityWithManyToOneMapping() to fail. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

1
2
0 / 0

[Hibernate-JIRA] Created: (HHH-6946) Add support for the AS400 (iSeries) system to StandardDialectResolver

by Nelson Rodrigues (JIRA)

Add support for the AS400 (iSeries) system to StandardDialectResolver --------------------------------------------------------------------- Key: HHH-6946 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6946 Project: Hibernate Core Issue Type: Improvement Components: core Affects Versions: 3.6.9, 4.0.0.Final Reporter: Nelson Rodrigues StandardDialectResolver currently uses the DB2Dialect for the AS400 systems. Hibernate has an DB2400Dialect better suited for this system. Improve StandardDialectResolver to choose this dialect. The databaseProductName for this system is DB2 UDB for AS/400, the correct dialect is org.hibernate.dialect.DB2400Dialect -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

3
4
0 / 0

[Hibernate-JIRA] Created: (HHH-7062) upgrade to jboss-logging 3.1.0.GA

by Strong Liu (JIRA)

upgrade to jboss-logging 3.1.0.GA --------------------------------- Key: HHH-7062 URL: https://hibernate.onjira.com/browse/HHH-7062 Project: Hibernate ORM Issue Type: Task Reporter: Strong Liu Assignee: Strong Liu Fix For: 4.1.x upgrade : * jboss-logging 3.1.0.CR2 --> 3.1.0.GA * jboss-logging-processor 1.0.0.CR5 --> 1.0.0.Final -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

1
1
0 / 0

[Hibernate-JIRA] Created: (HHH-7061) Fixed boolean literals in Derby versions 10.7+

by Strong Liu (JIRA)

Fixed boolean literals in Derby versions 10.7+ ---------------------------------------------- Key: HHH-7061 URL: https://hibernate.onjira.com/browse/HHH-7061 Project: Hibernate ORM Issue Type: Bug Components: core Affects Versions: 4.1.0 Reporter: Strong Liu Assignee: Strong Liu Fix For: 5.0.0 Derby 10.7 and later support a boolean data type, DerbyTenSevenDialect registers the type but doesn't override the toBooleanValueString method to return the literal values "true" and "false" -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

1
1
0 / 0

[Hibernate-JIRA] Created: (HHH-7018) See if the EntityManagerFactory serialization could use the EntityManagerFactory.serialize (just serialize the name)

by Scott Marlow (JIRA)

See if the EntityManagerFactory serialization could use the EntityManagerFactory.serialize (just serialize the name) -------------------------------------------------------------------------------------------------------------------- Key: HHH-7018 URL: https://hibernate.onjira.com/browse/HHH-7018 Project: Hibernate ORM Issue Type: Task Components: entity-manager Affects Versions: 4.0.1 Reporter: Scott Marlow Fix For: 4.1.0 -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

3
6
0 / 0

[Hibernate-JIRA] Created: (HHH-7058) Move away from storing Tuple on Table

by Steve Ebersole (JIRA)

Move away from storing Tuple on Table ------------------------------------- Key: HHH-7058 URL: https://hibernate.onjira.com/browse/HHH-7058 Project: Hibernate ORM Issue Type: Improvement Components: core, metamodel Reporter: Steve Ebersole Assignee: Steve Ebersole -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

1
2
0 / 0

[Hibernate-JIRA] Created: (JPA-14) OPTIMISTIC_FORCE_INCREMENT is not incrementing version field of non-dirty entities

by Behrang Saeedzadeh (JIRA)

OPTIMISTIC_FORCE_INCREMENT is not incrementing version field of non-dirty entities ---------------------------------------------------------------------------------- Key: JPA-14 URL: http://opensource.atlassian.com/projects/hibernate/browse/JPA-14 Project: Java Persistence API Issue Type: Bug Environment: MySQL 5.1.53 with InnoDB, Hibernate 3.1.6 Final, Java 1.6.0_22 Reporter: Behrang Saeedzadeh According to the JPA 2 spec: {quote} If transaction T1 calls {{lock(entity, LockModeType.OPTIMISTIC_FORCE_INCREMENT)}} on a versioned object, the entity manager must avoid the phenomena P1 and P2 (as with {{LockModeType.OPTIMISTIC}}) and must also force an update (increment) to the entity's version column. A forced version update may be performed immediately, or may be deferred until a flush or commit. If an entity is removed before a deferred version update was to have been applied, the forced version update is omitted. {quote} However, Hibernate is not incrementing the version field when the entity is not altered in the transaction: {code} final EntityManager em = factory.createEntityManager(); em.getTransaction().begin(); VersionedEntity entity = em.find(VersionedEntity.class, id); em.lock(entity, LockModeType.PESSIMISTIC_FORCE_INCREMENT); em.getTransaction().commit(); em.close(); {code} However, the spec says ??must also force an update (increment) to the entity's version column?? and does not give the option to ignore updating the version number if the entity was not dirty. -- 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, 1 month

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-6042) To much columns in select queries after creating criteria with join

by Karol Kowalczyk (JIRA)

To much columns in select queries after creating criteria with join ------------------------------------------------------------------- Key: HHH-6042 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6042 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.2.6 Environment: <dependency> <groupId>org.hibernate</groupId> <artifactId>hibernate</artifactId> <version>3.2.6.ga</version> </dependency> Any database Reporter: Karol Kowalczyk Attachments: AbstractEntityJoinWalker.java, Loader.java When I create criteria for any class with any value of property of association f.e.: java code: eventDCriteria = DetachedCriteria.forClass(Event.class); personDCriteria = eventDCriteria.createCriteria("participants"); personDCriteria.add(Expression.eq("age", 41)); List<Event> events=(List<Event>)getHibernateTemplate().findByCriteria(eventDCriteria, 0, 2); class mappings: <class name="Event" table="EVENTS"> <id name="id" column="EVENT_ID"> <generator class="native"/> </id> <property name="date" type="timestamp" column="EVENT_DATE"/> <property name="title"/> <set name="participants" table="PERSON_EVENT" inverse="true"> <key column="EVENT_ID"/> <many-to-many column="PERSON_ID" class="Person"/> </set> </class> <class name="Person" table="PERSON"> <id name="id" column="PERSON_ID"> <generator class="native"/> </id> <property name="age"/> <property name="firstname"/> <property name="lastname"/> <set name="events" table="PERSON_EVENT" > <key column="PERSON_ID"/> <many-to-many column="EVENT_ID" class="Event"/> </set> <set name="emailAddresses" table="PERSON_EMAIL_ADDR" > <key column="PERSON_ID"/> <element type="string" column="EMAIL_ADDR"/> </set> </class> a Hibernate still creates select query f.e.: select e.EVENT_ID, e.EVENT_DATE, e.title, pe.EVENT_ID, pe.PERSON_ID, p.PERSON_ID, p.age, p.firstname, ... from EVENTS e inner join PERSON_EVENT pe on pe.EVENT_ID=e.EVENT_ID inner join PERSON p on p.PERSON_ID=pe.PERSON_ID where p.age=?; Why this hibernates query have UNNECESSARY list of columns: pe.EVENT_ID, pe.PERSON_ID, p.PERSON_ID, p.age, p.firstname, ...? This query is not INDEXONLY for any databases. More EFFECTIVE query is: select e.EVENT_ID, e.EVENT_DATE, e.title from EVENTS e inner join PERSON_EVENT pe on pe.EVENT_ID=e.EVENT_ID inner join PERSON p on p.PERSON_ID=pe.PERSON_ID where p.age=?; A prepared only for my two changes in hibernate: Loader.java and AbstractEntityJoinWalker.java to get more effective selects. -- 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, 1 month

2
4
0 / 0

[Hibernate-JIRA] Commented: (HHH-158) nested DetachedCriteria throwing NullPointerException

by Anthony Whitford (JIRA)

[ https://hibernate.onjira.com/browse/HHH-158?page=com.atlassian.jira.plugi... ] Anthony Whitford commented on HHH-158: -------------------------------------- I've hit this issue using Hibernate version 3.2.5.ga. Has anyone made progress since the previous update 4 years ago? > nested DetachedCriteria throwing NullPointerException > ----------------------------------------------------- > > Key: HHH-158 > URL: https://hibernate.onjira.com/browse/HHH-158 > Project: Hibernate ORM > Issue Type: Bug > Components: core > Affects Versions: 3.0 beta 4 > Reporter: Jérôme Boehm > Assignee: Gavin King > Attachments: testcase.zip > > > It seems that it is not possible to nest DetachedCriteria. > This is examplified in the testWithReturnedObject() method of the attached TestCase. > When nesting DetachedCriteria using DetachedCriteria.add(Subqueries.<a_Subqueries_static_method>) twice, we get the following exception: > java.lang.NullPointerException > at org.hibernate.criterion.SubqueryExpression.getTypedValues(SubqueryExpression.java:73) > at org.hibernate.loader.criteria.CriteriaQueryTranslator.getQueryParameters(CriteriaQueryTranslator.java:230) > at org.hibernate.criterion.SubqueryExpression.toSqlString(SubqueryExpression.java:50) > at org.hibernate.criterion.Junction.toSqlString(Junction.java:58) > at org.hibernate.loader.criteria.CriteriaQueryTranslator.getWhereCondition(CriteriaQueryTranslator.java:312) > at org.hibernate.loader.criteria.CriteriaLoader.<init>(CriteriaLoader.java:92) > at org.hibernate.impl.SessionImpl.list(SessionImpl.java:1208) > at org.hibernate.impl.CriteriaImpl.list(CriteriaImpl.java:299) > at test.subqueries.SubqueriesTest.main(SubqueriesTest.java:41) > Then, after "correcting" SubqueryExpression so that the params instance variable is initialized (see the attached Corrected_SubqueryExpression), it seems that the nested aliases are not properly propagated, which is examplified in testWithNoReturnedObject(). > The generated sql is: > select this_.a_id as a1_0_ from a this_ where exists (select this0__.b_id as y0_ from b this0__ where this0__.a_id=this_.a_id and exists (select this0__.c_id as y0_ from c this0__ where this0__.b_id=this0__.b_id)) > I think it should be (notice the this1__ alias for table c): > select this_.a_id as a1_0_ from a this_ where exists (select this0__.b_id as y0_ from b this0__ where this0__.a_id=this_.a_id and exists (select this1__.c_id as y0_ from c this1__ where this1__.b_id=this0__.b_id)) -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

14 years, 1 month

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues February 2012