February 2012 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Commented: (HHH-1283) ScrollableResults JoinFetch don't set child collection correctly　after the second parent object

by Frans Flippo (JIRA)

[ https://hibernate.onjira.com/browse/HHH-1283?page=com.atlassian.jira.plug... ] Frans Flippo commented on HHH-1283: ----------------------------------- A warning in the manual that you should ORDER BY <parent> is better than the current situation which can't be made workable at all. I propose to apply the patch to the Hibernate source and add a comment in the manual. Perhaps a better fix can be made later for the long term. > ScrollableResults JoinFetch don't set child collection correctly　after the second parent object > ----------------------------------------------------------------------------------------------- > > Key: HHH-1283 > URL: https://hibernate.onjira.com/browse/HHH-1283 > Project: Hibernate ORM > Issue Type: Bug > Components: core > Affects Versions: 3.1 > Environment: Hibernate 3.1 > Oracle10gR2 > Oracle JDBC Driver 10.2.0.1.0 > Sun JDK 1.5.0_06 > Spring 1.2.6 > Reporter: Masahiro Hirashima > Attachments: fetch-scroll-collection-3.5.4.patch, ScrollableCollectionFetchingTest.java, ScrollableResults.zip > > > ScrollableResults JoinFetch set child collection correctly at first parent object. > but after the second parent object, It set only the first element of a child collection. > I made the following tables. > CREATE TABLE owners ( > id NUMBER(36, 0) NOT NULL PRIMARY KEY, > first_name VARCHAR(30), > last_name VARCHAR(30), > address VARCHAR(255), > city VARCHAR(80), > telephone VARCHAR(20), > version NUMBER(36, 0) DEFAULT 0 > ); > CREATE TABLE types ( > id NUMBER(36, 0) NOT NULL PRIMARY KEY, > name VARCHAR(80), > version NUMBER(36, 0) DEFAULT 0 > ); > CREATE TABLE pets ( > id NUMBER(36, 0) NOT NULL PRIMARY KEY, > name VARCHAR(30), > birth_date DATE, > type_id NUMBER(36, 0), > owner_id NUMBER(36, 0), > version NUMBER(36, 0) DEFAULT 0 > ); > and inserted the following data. > INSERT INTO owners VALUES (1, 'Betty', 'Davis', '638 Cardinal Ave.', 'Sun Prairie', '6085551749', 0); > INSERT INTO owners VALUES (2, 'Eduardo', 'Rodriquez', '2693 Commerce St.', 'McFarland', '6085558763', 0); > INSERT INTO pets VALUES (1, 'Leo', '2000-09-07', 1, 1, 0); > INSERT INTO pets VALUES (2, 'Basil', '2002-08-06', 2, 1, 0); > INSERT INTO pets VALUES (3, 'Rosy', '2001-04-17', 3, 2, 0); > INSERT INTO pets VALUES (4, 'Jewel', '2000-03-07', 4, 2, 0); > INSERT INTO pets VALUES (5, 'Iggy', '2000-11-30', 5, 2, 0); > INSERT INTO types VALUES (1, 'cat', 0); > INSERT INTO types VALUES (2, 'dog', 0); > INSERT INTO types VALUES (3, 'lizard', 0); > INSERT INTO types VALUES (4, 'snake', 0); > INSERT INTO types VALUES (5, 'bird', 0); > and I execute following code. > String hqlJoinFetchTest = > "from Owner owner " + > "left outer join fetch owner.pets as pets " + > "left outer join fetch pets.type " + > "order by owner.firstName, owner.lastName"; > Query query = session.createQuery(hqlJoinFetchTest); > ScrollableResults cursor = query.scroll(); > while ( cursor.next() ) { > Owner owner = (Owner)cursor.get(0); > System.out.println(owner); > } > result of this code is following. > petclinic.domain.Owner@15d616e[id=1,version=0,firstName=Betty,lastName=Davis, > petclinic.domain.Pet@136d9d8[id=2,version=0,name=Basil,birthDate=2002-08-06, > petclinic.domain.PetType@1be2893[id=2,version=0,name=dog] > petclinic.domain.Pet@14a75bb[id=1,version=0,name=Leo,birthDate=2000-09-07, > petclinic.domain.PetType@17779e3[id=1,version=0,name=cat] > petclinic.domain.Owner@e3570c[id=2,version=0,firstName=Eduardo,lastName=Rodriquez > petclinic.domain.Pet@167e3a5[id=4,version=0,name=Jewel,birthDate=2000-03-07, > petclinic.domain.PetType@1926e90[id=4,version=0,name=snake] > First owner object set collection collectly. > but second owner object don't set second pet object(id=5) and third pet object(id=6). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
0
0 / 0

[Hibernate-JIRA] Created: (OGM-118) Dialect could provide information about supported lock/isolation levels

by Sanne Grinovero (JIRA)

Dialect could provide information about supported lock/isolation levels ----------------------------------------------------------------------- Key: OGM-118 URL: https://hibernate.onjira.com/browse/OGM-118 Project: Hibernate OGM Issue Type: Improvement Reporter: Sanne Grinovero It could be useful to verify for expected lock capabilities at boot time to avoid runtime errors, if we figure out how to know which levels are expected to be needed. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-7091) right function in HQL update gives parser exception

by Willis Blackburn (JIRA)

right function in HQL update gives parser exception --------------------------------------------------- Key: HHH-7091 URL: https://hibernate.onjira.com/browse/HHH-7091 Project: Hibernate ORM Issue Type: Bug Affects Versions: 3.6.7 Environment: H2Dialect Reporter: Willis Blackburn Priority: Minor Tried to execute an HQL statement that looked like this: update Item i set i.path = right(i.path, length(i.path)) The update is a no-op. Hibernate can't parse it: unexpected token: right near line 1, column 32 [update v3g.Item i set i.path = right(i.path, length(i.path))] However the equivalent with substring works just fine: update Item i set i.path = substring(i.path, 1, length(i.path)) Maybe Hibernate is getting confused because "right" is both a function (defined in H2Dialect) and a keyword (as in "right join"). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-7088) Implement secondary table support in new metamodel code

by Steve Ebersole (JIRA)

Implement secondary table support in new metamodel code ------------------------------------------------------- Key: HHH-7088 URL: https://hibernate.onjira.com/browse/HHH-7088 Project: Hibernate ORM Issue Type: Task Components: core, metamodel Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 5.0.0 In terms of the SPI, lets follow the JPA approach of conceptualization where column-sources would have to name the table to which they belong. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-6441) Consider not storing Tuple values on Table

by Steve Ebersole (JIRA)

Consider not storing Tuple values on Table ------------------------------------------ Key: HHH-6441 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-6441 Project: Hibernate Core Issue Type: Improvement Components: core, metamodel Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 4.0.0.next Essentially, limit to SimpleValues (column,formula). Tuple would still be useful for use on keys, bindings, etc. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
4
0 / 0

[Hibernate-JIRA] Created: (HHH-7087) Allow projection on collections

by Andrew Radcliffe (JIRA)

Allow projection on collections ------------------------------- Key: HHH-7087 URL: https://hibernate.onjira.com/browse/HHH-7087 Project: Hibernate ORM Issue Type: Improvement Components: query-criteria Affects Versions: 4.1.0 Reporter: Andrew Radcliffe Priority: Minor Projection on a field that is a collection does not work (null is returned). It would be great if support for this could be added. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
0
0 / 0

[Hibernate-JIRA] Commented: (HHH-979) Merge operation should retain existing identifiers

by Eugen Paraschiv (JIRA)

[ https://hibernate.onjira.com/browse/HHH-979?page=com.atlassian.jira.plugi... ] Eugen Paraschiv commented on HHH-979: ------------------------------------- I see the resolution to this is `Rejected` - can someone explain the reasoning behind this? This behaviour is something you'd reasonably expect - for example, creating a new entity, setting a random id on it and merging should (in my view) fail with some sort of not found exception. Instead, the detached entity is persisted, and the existing id silently ignored. There may be valid reasons to do so - but I do think some quick info on this would be helpful to understand why. Thank you. > Merge operation should retain existing identifiers > -------------------------------------------------- > > Key: HHH-979 > URL: https://hibernate.onjira.com/browse/HHH-979 > Project: Hibernate ORM > Issue Type: Improvement > Components: core > Affects Versions: 3.0.5 > Reporter: Aleksei Valikov > Priority: Minor > Original Estimate: 20m > Remaining Estimate: 20m > > Currently, merge(...) operation does not retain existing object identifiers. > Here's a demonstrating test case: > public void testIt() throws Exception { > final A a1 = new A(); > final B b1 = new B(); > a1.setId("A"); > a1.setB(b1); > a1.setD("d1"); > b1.setId("B"); > b1.setC("c1"); > save(a1); > > final A a2 = new A(); > final B b2 = new B(); > a2.setId("A"); > a2.setB(b2); > a2.setD("d2"); > b2.setId("B"); > b2.setC("c2"); > save(a2); > > final A a3 = load("A"); > > assertEquals(a3.getD(), a2.getD()); > assertEquals(a3.getB().getC(), a2.getB().getC()); > } > > public void save(A a) > { > final Session s = openSession(); > final Transaction t = s.beginTransaction(); > s.merge(a); > t.commit(); > s.close(); > } > > public A load(String id) > { > final Session s = openSession(); > final A a = (A) s.get(A.class, id); > s.close(); > return a; > } > load("A") returns null since merged objects have newly generated identifiers. Moreover, we get two entities persisted in the DB, not one: > INSERT INTO B VALUES('4028e4fc067e203f01067e2042690001','c1') > INSERT INTO A VALUES('4028e4fc067e203f01067e2042790002','4028e4fc067e203f01067e2042690001','d1') > COMMIT > INSERT INTO B VALUES('4028e4fc067e203f01067e2042e60003','c2') > INSERT INTO A VALUES('4028e4fc067e203f01067e2042e60004','4028e4fc067e203f01067e2042e60003','d2') > COMMIT > I think a more sensible behaviour is to retain identifiers. This can be achieved with a one-line code patch. > Before DefaultMergeEventListener.entityIsDetached(...) calls entityIsTransient(), it should set event.requestedId: > // .... > Serializable id = event.getRequestedId(); > if ( id == null ) { > id = persister.getIdentifier( entity, source.getEntityMode() ); > } > else { > //TODO: check that entity id = requestedId > } > final Object result = source.get(entityName, id); > if ( result == null ) { > //TODO: we should throw an exception if we really *know* for sure > // that this is a detached instance, rather than just assuming > //throw new StaleObjectStateException(entityName, id); > event.setRequestedId(id); > > // we got here because we assumed that an instance > // with an assigned id was detached, when it was > // really persistent > return entityIsTransient(event, copyCache); > } > // ... > This results in following DB operations: > INSERT INTO B VALUES('B','c1') > INSERT INTO A VALUES('A','B','d1') > COMMIT > DELETE FROM B WHERE ID='B' > INSERT INTO B VALUES('B','c2') > DELETE FROM A WHERE ID='A' > INSERT INTO A VALUES('A','B','d2') > COMMIT > At the moment, I've implemented is as my own listener, but would like in any case to know your opinion. > Anyways, something like MergeMode (analogous to ReplicationMode) would be also nice to have. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 10 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HV-524) java.util.NoSuchElementException in type level validation using EclipseLink

by sinuhepop (JIRA)

java.util.NoSuchElementException in type level validation using EclipseLink --------------------------------------------------------------------------- Key: HV-524 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-524 Project: Hibernate Validator Issue Type: Bug Components: validators Affects Versions: 4.2.0.Final Environment: EclipseLink 2.2.0 Reporter: sinuhepop When EclipseLink obtains an entity from database does a validation. It works ok with field level validators, but throws an exception with type level ones. The problem is that SingleThreadCachedTraversableResolver sends an "empty" pathToTraversableObject to EL's BeanValidationListener, who finally fails when calling "pathToTraversableObject.iterator().next().getName()". I don't know who (HV or EL) is responsible of the issue, but it worked with HV-4.0.2.GA. Thanks for your effort. Sinuhé. Caused by: javax.validation.ValidationException: Call to TraversableResolver.isReachable() threw an exception at org.hibernate.validator.engine.ValidatorImpl.isValidationRequired(ValidatorImpl.java:1251) ~[hibernate-validator-4.2.0.Final.jar:4.2.0.Final] at org.hibernate.validator.engine.ValidatorImpl.validateConstraint(ValidatorImpl.java:448) ~[hibernate-validator-4.2.0.Final.jar:4.2.0.Final] at org.hibernate.validator.engine.ValidatorImpl.validateConstraintsForDefaultGroup(ValidatorImpl.java:397) ~[hibernate-validator-4.2.0.Final.jar:4.2.0.Final] at org.hibernate.validator.engine.ValidatorImpl.validateConstraintsForCurrentGroup(ValidatorImpl.java:361) ~[hibernate-validator-4.2.0.Final.jar:4.2.0.Final] at org.hibernate.validator.engine.ValidatorImpl.validateInContext(ValidatorImpl.java:313) ~[hibernate-validator-4.2.0.Final.jar:4.2.0.Final] at org.hibernate.validator.engine.ValidatorImpl.validate(ValidatorImpl.java:139) ~[hibernate-validator-4.2.0.Final.jar:4.2.0.Final] at org.eclipse.persistence.internal.jpa.metadata.listeners.BeanValidationListener.validateOnCallbackEvent(BeanValidationListener.java:84) ~[eclipselink-2.2.0.jar:2.2.0.v20110202-r8913] at org.eclipse.persistence.internal.jpa.metadata.listeners.BeanValidationListener.preUpdate(BeanValidationListener.java:72) ~[eclipselink-2.2.0.jar:2.2.0.v20110202-r8913] at org.eclipse.persistence.descriptors.DescriptorEventManager.notifyListener(DescriptorEventManager.java:671) ~[eclipselink-2.2.0.jar:2.2.0.v20110202-r8913] at org.eclipse.persistence.descriptors.DescriptorEventManager.notifyEJB30Listeners(DescriptorEventManager.java:641) ~[eclipselink-2.2.0.jar:2.2.0.v20110202-r8913] at org.eclipse.persistence.descriptors.DescriptorEventManager.executeEvent(DescriptorEventManager.java:200) ~[eclipselink-2.2.0.jar:2.2.0.v20110202-r8913] at org.eclipse.persistence.descriptors.changetracking.DeferredChangeDetectionPolicy.calculateChanges(DeferredChangeDetectionPolicy.java:85) ~[eclipselink-2.2.0.jar:2.2.0.v20110202-r8913] at org.eclipse.persistence.descriptors.changetracking.DeferredChangeDetectionPolicy.calculateChangesForExistingObject(DeferredChangeDetectionPolicy.java:54) ~[eclipselink-2.2.0.jar:2.2.0.v20110202-r8913] at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.calculateChanges(UnitOfWorkImpl.java:623) ~[eclipselink-2.2.0.jar:2.2.0.v20110202-r8913] at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.commitToDatabaseWithChangeSet(UnitOfWorkImpl.java:1496) ~[eclipselink-2.2.0.jar:2.2.0.v20110202-r8913] at org.eclipse.persistence.internal.sessions.RepeatableWriteUnitOfWork.commitRootUnitOfWork(RepeatableWriteUnitOfWork.java:264) ~[eclipselink-2.2.0.jar:2.2.0.v20110202-r8913] at org.eclipse.persistence.internal.sessions.UnitOfWorkImpl.commitAndResume(UnitOfWorkImpl.java:1130) ~[eclipselink-2.2.0.jar:2.2.0.v20110202-r8913] at org.eclipse.persistence.internal.jpa.transaction.EntityTransactionImpl.commitInternal(EntityTransactionImpl.java:84) ~[eclipselink-2.2.0.jar:2.2.0.v20110202-r8913] ... 73 common frames omitted Caused by: java.util.NoSuchElementException: null at java.util.Collections$EmptyIterator.next(Unknown Source) ~[na:1.7.0] at org.eclipse.persistence.internal.jpa.metadata.listeners.BeanValidationListener$AutomaticLifeCycleValidationTraversableResolver.isRootObjectPath(BeanValidationListener.java:180) ~[eclipselink-2.2.0.jar:2.2.0.v20110202-r8913] at org.eclipse.persistence.internal.jpa.metadata.listeners.BeanValidationListener$AutomaticLifeCycleValidationTraversableResolver.isReachable(BeanValidationListener.java:123) ~[eclipselink-2.2.0.jar:2.2.0.v20110202-r8913] at org.hibernate.validator.engine.resolver.SingleThreadCachedTraversableResolver.isReachable(SingleThreadCachedTraversableResolver.java:46) ~[hibernate-validator-4.2.0.Final.jar:4.2.0.Final] at org.hibernate.validator.engine.ValidatorImpl.isValidationRequired(ValidatorImpl.java:1242) ~[hibernate-validator-4.2.0.Final.jar:4.2.0.Final] ... 90 common frames omitted -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

5
20
0 / 0

[Hibernate-JIRA] Created: (HHH-7083) Error log not print stacktrace

by Evgeny Terentev (JIRA)

Error log not print stacktrace ------------------------------- Key: HHH-7083 URL: https://hibernate.onjira.com/browse/HHH-7083 Project: Hibernate ORM Issue Type: Improvement Reporter: Evgeny Terentev Priority: Trivial in SqlExceptionHelper if log level ERROR hibernate not print stacktrace, only print message public void logExceptions( SQLException sqlException, String message ) { if (LOG.isEnabled(Level.ERROR)) { if (LOG.isDebugEnabled()) { message = StringHelper.isNotEmpty(message) ? message : DEFAULT_EXCEPTION_MSG; LOG.debug( message, sqlException ); } while (sqlException != null) { StringBuilder buf = new StringBuilder(30).append("SQL Error: ").append(sqlException.getErrorCode()).append(", SQLState: ").append(sqlException.getSQLState()); LOG.warn(buf.toString()); LOG.error(sqlException.getMessage()); sqlException = sqlException.getNextException(); } } } -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-7082) Please change my email

by Bernard (JIRA)

Please change my email ---------------------- Key: HHH-7082 URL: https://hibernate.onjira.com/browse/HHH-7082 Project: Hibernate ORM Issue Type: Task Reporter: Bernard I can't find an option in my profile to change my email. Please contact me. My username is bht. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira

12 years, 11 months

1
0
0 / 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues February 2012