July 2007 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HSHARDS-36) Support Hibernate Annotations

by Emmanuel Bernard (JIRA)

Support Hibernate Annotations ----------------------------- Key: HSHARDS-36 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSHARDS-36 Project: Hibernate Shards Issue Type: New Feature Components: configuration Reporter: Emmanuel Bernard Assignee: Max Ross http://forum.hibernate.org/viewtopic.php?p=2356765#2356765 -- 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

16 years, 11 months

3
3
0 / 0

[Hibernate-JIRA] Created: (ANN-602) SecondaryTable with EmbeddedId and IdClass is broken

by Chandra (JIRA)

SecondaryTable with EmbeddedId and IdClass is broken ---------------------------------------------------- Key: ANN-602 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-602 Project: Hibernate Annotations Issue Type: Bug Components: binder Affects Versions: 3.3.0.ga Environment: Hibernate Core 3.2.3 GA Hibernate Annotations 3.3.0.GA hibernate-entitymanager-3.3.1.GA Reporter: Chandra Attachments: CompositeIdTest.java, TvProgram.java, TvProgramIdClass.java I added following two classes (TvProgram and TvProgramIdClass) in org.hibernate.test.annotations.cid package. And added two test cases to org.hibernate.test.annotations.cid.CompositeIdTest. See testSecondaryTableWithCompositeId and testSecondaryTableWithIdClass methods in attached fi The test cases fail with following output. However, if I remove SecondaryTable and secondary table @Column, test cases pass. 12:43:15,534 INFO Version:15 - Hibernate Annotations 3.3.0.GA 12:43:15,550 INFO Environment:509 - Hibernate 3.2.3 12:43:15,565 INFO Environment:527 - loaded properties from resource hibernate.properties: {hibernate.connection.password=****, hibernate.jdbc.batch_versioned_data=true, hibernate.query.substitutions=true 1, false 0, yes 'Y', no 'N', hibernate.cache.region_prefix=hibernate.test, hibernate.proxool.pool_alias=pool1, hibernate.bytecode.use_reflection_optimizer=false, hibernate.default_batch_fetch_size=100, hibernate.cache.use_query_cache=true, hibernate.jdbc.use_streams_for_binary=true, hibernate.max_fetch_depth=1, hibernate.format_sql=true, hibernate.connection.pool_size=1, hibernate.connection.username=sa, hibernate.connection.driver_class=org.hsqldb.jdbcDriver, hibernate.cache.provider_class=org.hibernate.cache.HashtableCacheProvider, hibernate.order_updates=true, hibernate.dialect=org.hibernate.dialect.HSQLDialect, hibernate.connection.url=jdbc:hsqldb:.} 12:43:15,565 INFO Environment:558 - using java.io streams to persist binary types 12:43:15,581 INFO Environment:676 - Bytecode provider name : cglib 12:43:15,581 INFO Environment:593 - using JDK 1.4 java.sql.Timestamp handling 12:43:15,675 INFO Dialect:152 - Using dialect: org.hibernate.dialect.HSQLDialect 12:43:15,815 INFO AnnotationBinder:398 - Binding entity from annotated class: org.hibernate.test.annotations.cid.Parent 12:43:15,862 INFO EntityBinder:420 - Bind entity org.hibernate.test.annotations.cid.Parent on table Parent 12:43:15,894 INFO AnnotationBinder:398 - Binding entity from annotated class: org.hibernate.test.annotations.cid.Child 12:43:15,909 INFO EntityBinder:420 - Bind entity org.hibernate.test.annotations.cid.Child on table Child 12:43:15,925 INFO AnnotationBinder:398 - Binding entity from annotated class: org.hibernate.test.annotations.cid.Channel 12:43:15,925 INFO EntityBinder:420 - Bind entity org.hibernate.test.annotations.cid.Channel on table Channel 12:43:15,941 INFO AnnotationBinder:398 - Binding entity from annotated class: org.hibernate.test.annotations.cid.TvMagazin 12:43:15,941 INFO EntityBinder:420 - Bind entity org.hibernate.test.annotations.cid.TvMagazin on table TvMagazin 12:43:15,941 INFO AnnotationBinder:398 - Binding entity from annotated class: org.hibernate.test.annotations.cid.TvProgramIdClass 12:43:15,941 INFO EntityBinder:420 - Bind entity org.hibernate.test.annotations.cid.TvProgramIdClass on table TvProgramIdClass 12:43:15,956 INFO EntityBinder:631 - Adding secondary table to entity org.hibernate.test.annotations.cid.TvProgramIdClass -> TV_PROGRAM_IDCLASS java.util.NoSuchElementException at java.util.AbstractList$Itr.next(AbstractList.java:427) at org.hibernate.util.JoinedIterator.next(JoinedIterator.java:53) at org.hibernate.cfg.Ejb3JoinColumn.buildJoinColumn(Ejb3JoinColumn.java:210) at org.hibernate.cfg.annotations.EntityBinder.createPrimaryColumnsToSecondaryTable(EntityBinder.java:483) at org.hibernate.cfg.annotations.EntityBinder.finalSecondaryTableBinding(EntityBinder.java:440) at org.hibernate.cfg.AnnotationBinder.bindClass(AnnotationBinder.java:770) at org.hibernate.cfg.AnnotationConfiguration.processArtifactsOfType(AnnotationConfiguration.java:498) at org.hibernate.cfg.AnnotationConfiguration.secondPassCompile(AnnotationConfiguration.java:277) at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1286) at org.hibernate.cfg.AnnotationConfiguration.buildSessionFactory(AnnotationConfiguration.java:915) at org.hibernate.test.annotations.TestCase.buildSessionFactory(TestCase.java:51) at org.hibernate.test.annotations.TestCase.setUp(TestCase.java:61) at junit.framework.TestCase.runBare(TestCase.java:125) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at junit.textui.TestRunner.doRun(TestRunner.java:116) at com.intellij.rt.execution.junit.IdeaTestRunner.doRun(IdeaTestRunner.java:65) at junit.textui.TestRunner.doRun(TestRunner.java:109) at com.intellij.rt.execution.junit.IdeaTestRunner.startRunnerWithArgs(IdeaTestRunner.java:24) at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:118) at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:40) 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:585) at com.intellij.rt.execution.application.AppMain.main(AppMain.java:90) java.util.NoSuchElementException at java.util.AbstractList$Itr.next(AbstractList.java:427) at org.hibernate.util.JoinedIterator.next(JoinedIterator.java:53) at org.hibernate.cfg.Ejb3JoinColumn.buildJoinColumn(Ejb3JoinColumn.java:210) at org.hibernate.cfg.annotations.EntityBinder.createPrimaryColumnsToSecondaryTable(EntityBinder.java:483) at org.hibernate.cfg.annotations.EntityBinder.finalSecondaryTableBinding(EntityBinder.java:440) at org.hibernate.cfg.AnnotationBinder.bindClass(AnnotationBinder.java:770) at org.hibernate.cfg.AnnotationConfiguration.processArtifactsOfType(AnnotationConfiguration.java:498) at org.hibernate.cfg.AnnotationConfiguration.secondPassCompile(AnnotationConfiguration.java:277) at org.hibernate.cfg.Configuration.buildSessionFactory(Configuration.java:1286) at org.hibernate.cfg.AnnotationConfiguration.buildSessionFactory(AnnotationConfiguration.java:915) at org.hibernate.test.annotations.TestCase.buildSessionFactory(TestCase.java:51) at org.hibernate.test.annotations.TestCase.setUp(TestCase.java:61) at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:40) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at com.intellij.rt.execution.application.AppMain.main(AppMain.java:90) -- 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

16 years, 11 months

2
2
0 / 0

[Hibernate-JIRA] Commented: (HHH-1743) Wrong order of binding parameters in Restrictions.in for composite primary keys

by Chris Bredesen (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1743?page=c... ] Chris Bredesen commented on HHH-1743: ------------------------------------- One workaround is to use HQL. Binding a parameter list of composite types seems to work. > Wrong order of binding parameters in Restrictions.in for composite primary keys > ------------------------------------------------------------------------------- > > Key: HHH-1743 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1743 > Project: Hibernate3 > Issue Type: Bug > Components: query-criteria > Affects Versions: 3.2.0 cr1 > Environment: Windows XP, Oracle 10g > Reporter: Viatcheslav Sysoltsev (Slavka) > Attachments: HibernateTest_restrictions_in_parameter_binding.zip > > Original Estimate: 1 hour > Remaining Estimate: 1 hour > > There is a table Person with composite primary key: > PERSON > primary key fields: > FAMILY > NUMBER > For the Criteria Query like > List<PersonId> ids = new Vector<PersonId>(); > ids.add(new PersonId("SLAVA1", 10L)); > ids.add(new PersonId("SLAVA2", 20L)); > ids.add(new PersonId("SLAVA3", 30L)); > List<Person> persons = session.createCriteria(Person.class) > .add(Restrictions.in("id", ids)) > .list(); > the query is generated > select this_.FAMILY as FAMILY0_0_, this_.NUMBER as NUMBER0_0_ from PERSON this_ where (this_.FAMILY, this_.NUMBER) in ((?, ?), (?, ?), (?, ?)) > The query is right, but the parameters are bound in wrong order, here is the excerpt from the log: > 16:21:33,221 DEBUG [SQL] select this_.FAMILY as FAMILY0_0_, this_.NUMBER as NUMBER0_0_ from PERSON this_ where (this_.FAMILY, this_.NUMBER) in ((?, ?), (?, ?), (?, ?)) > Hibernate: select this_.FAMILY as FAMILY0_0_, this_.NUMBER as NUMBER0_0_ from PERSON this_ where (this_.FAMILY, this_.NUMBER) in ((?, ?), (?, ?), (?, ?)) > 16:21:33,221 DEBUG [AbstractBatcher] preparing statement > 16:21:33,330 DEBUG [StringType] binding 'SLAVA1' to parameter: 1 > 16:21:33,330 DEBUG [StringType] binding 'SLAVA2' to parameter: 2 > 16:21:33,330 DEBUG [StringType] binding 'SLAVA3' to parameter: 3 > 16:21:33,330 DEBUG [LongType] binding '10' to parameter: 4 > 16:21:33,330 DEBUG [LongType] binding '20' to parameter: 5 > 16:21:33,330 DEBUG [LongType] binding '30' to parameter: 6 > I've made an example (attached, standalone eclipse project with all libs) which demonstrates the problem, but you need running oracle somewhere to run it. See also bug report HH-708 which is predecessor of this. > The problem may lay in org.hibernate.criterion.InExpression::getTypedValues. > Instead of > for ( int i=0; i<types.length; i++ ) { > for ( int j=0; j<values.length; j++ ) { > Object subval = values[j]==null ? > null : > actype.getPropertyValues( values[j], EntityMode.POJO )[i]; > list.add( new TypedValue( types[i], subval, EntityMode.POJO ) ); > } > } > should be > for ( int j=0; j<values.length; j++ ) { > for ( int i=0; i<types.length; i++ ) { > Object subval = values[j]==null ? > null : > actype.getPropertyValues( values[j], EntityMode.POJO )[i]; > list.add( new TypedValue( types[i], subval, EntityMode.POJO ) ); > } > } > After change have worked for me. But I am not sure whether the syntax of what's going from Restriction.in is database-specific. -- 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

16 years, 11 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HSHARDS-20) ShardedSessionImpl.merge(Object obj);

by Max Ross (JIRA)

ShardedSessionImpl.merge(Object obj); ------------------------------------- Key: HSHARDS-20 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSHARDS-20 Project: Hibernate Shards Issue Type: Task Components: engine Affects Versions: 3.0.0.Beta1 Reporter: Max Ross Assignee: Max Ross Fix For: 3.0.0.beta2 -- 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

16 years, 11 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HSHARDS-21) CLONE -ShardedSessionImpl.merge(String entityName, Object obj);

by Max Ross (JIRA)

CLONE -ShardedSessionImpl.merge(String entityName, Object obj); --------------------------------------------------------------- Key: HSHARDS-21 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSHARDS-21 Project: Hibernate Shards Issue Type: Task Components: engine Affects Versions: 3.0.0.Beta1 Reporter: Max Ross Assignee: Max Ross Fix For: 3.0.0.beta2 -- 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

16 years, 11 months

2
4
0 / 0

[Hibernate-JIRA] Created: (HHH-2717) toString() method with cyclic associations and a dynamic model causes StackOverflowException

by Stefan Wachter (JIRA)

toString() method with cyclic associations and a dynamic model causes StackOverflowException -------------------------------------------------------------------------------------------- Key: HHH-2717 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2717 Project: Hibernate3 Issue Type: Bug Affects Versions: 3.2.4.sp1 Environment: Hibernate 3.2.4.sp1; MySQL Reporter: Stefan Wachter When the toString() method is called on an entity (i.e. on a HashMap) then a StackOverflow occurs. The members of an association are stored in map entry with a PersistentList value. The PersistentList in turn contains HashMaps, that contain PersistentLists again, ... The toString() method must take care of cycles. -- 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

16 years, 11 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HSHARDS-38) Support different second level cache prefixes across shards

by Max Ross (JIRA)

Support different second level cache prefixes across shards ----------------------------------------------------------- Key: HSHARDS-38 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSHARDS-38 Project: Hibernate Shards Issue Type: New Feature Reporter: Max Ross Assignee: Max Ross Fix For: 3.0.0.beta2 hibernate.cache.region_prefix should be one of the config properties that can vary across shards. This will allow developers to make better use of the second level cache with shards. -- 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

16 years, 11 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HV-33) LengthValidator (@Length) should consider Character as valid

by Dan Allen (JIRA)

LengthValidator (@Length) should consider Character as valid ------------------------------------------------------------ Key: HV-33 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-33 Project: Hibernate Validator Issue Type: Improvement Components: validators Affects Versions: 3.0.0.ga Reporter: Dan Allen Priority: Minor Currently, the LengthValidator only considers values of type java.lang.String. However, if the validation is @Length(max = 1), it should consider a value of type java.lang.Character as valid. I realize that is a pointless validation, but it is valid. It came up because the reverse engineering tools places this validation on java.lang.Character and char properties. The fix just requires inserting the code below in the second line of the LengthValidator#isValid method. if ( ( value instanceof Character ) && max == 1 ) return true; -- 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

16 years, 11 months

1
0
0 / 0

[Hibernate-JIRA] Created: (EJB-303) Removing an entity and clearing the persistence context messes up FlushMode.AUTO

by Geoffrey De Smet (JIRA)

Removing an entity and clearing the persistence context messes up FlushMode.AUTO -------------------------------------------------------------------------------- Key: EJB-303 URL: http://opensource.atlassian.com/projects/hibernate/browse/EJB-303 Project: Hibernate Entity Manager Issue Type: Bug Components: EntityManager Affects Versions: 3.3.0.ga Reporter: Geoffrey De Smet Priority: Critical Remove an entity, then EM.clear() before EM.flush() with FlushMode.AUTO makes next querty still contain the removed entity. Try something like this: public void delete(Person detachedPerson) { int oldSize = entityManager.createQuery("select x from Person person").getResultList().size(); Person person = entityManager.merge(detachedPerson); entityManager.remove(person); entityManager.clear(); // causes the problem entityManager.flush(); // probably obsolete to prove this bug int newSize = entityManager.createQuery("select x from Person person").getResultList().size(); assertEquals(newSize, oldSize - 1); // they turn out to be still the same size } Not doing entityManager.clear() fixes the problem, but because I am not using an extended peristence context and my testcases run in a rollback transaction, I need to clear the entityManger after every service call (so between the service call delete and the service call findAll). I looked through the JIRA's, but it didn't look like it's already posted. -- 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

16 years, 11 months

2
1
0 / 0

[Hibernate-JIRA] Commented: (HHH-1869) The MultipleHiloPertablegenerator.class wraps at 2**31-1, but javadoc claims Long.

by Sylvain Mougenot (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1869?page=c... ] Sylvain Mougenot commented on HHH-1869: --------------------------------------- Because database numeric representation (that might be used for primary keys) is not limited to 32/64bits representation, why not upgrade this class to be as compliant (to big numbers) as possible by using BigInteger representation. Actually I've encountered the problem of overflow using this class!!!! Stack Trace sample: HibernateJdbcException: JDBC exception on Hibernate data access; nested exception is org.hibernate.exception.GenericJDBCException: could not get or update next value... Caused by java.sql.SQLException: JZ00B: Overflow numérique... (Localisation looks strange here) (Caused by ResultSet.getInt() on a too large value stored in the database) After one year no one seamed to take into account the consequences on users. In my point of view this bug is Fatal : - Database integrity is endangered or (at least) - Application could not operate on concerned tables (our case)! For so "trivial" changes fixing a big threat on users I hope there will be a fix soon! Please vote!!! > The MultipleHiloPertablegenerator.class wraps at 2**31-1, but javadoc claims Long. > ---------------------------------------------------------------------------------- > > Key: HHH-1869 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1869 > Project: Hibernate3 > Issue Type: Bug > Components: core > Affects Versions: 3.2.0 cr1 > Environment: All versions/all environments. > Reporter: Jan Helge Salvesen > Attachments: MultipleHiLoPerTableGenerator.zip > > > The returntype of org.hibernate.id.MultipleHiloPertablegenerator.doWorkInCurrentTransaction are Serializable, and the javadoc states that this class shall return a Long (line 26 in source-file). But the value to be returned are, in fact, treated as an Integer and thus limited to 31-bits positive numbers (as an Integer). See line 163 in class, for instance. This behaviour will cause problems for sequence numbers above Integer.MAX_VALUE (that is 2**31-1). When this limit is exceeded, the actual returned "Long" are a huge-negative integer and may potentinally cause damage. The reason for Priority:Major is the fact that user of this class may have an old-fashon databasescheme, and for this reason, this error may become a "ticking bomb" waiting to a sequence number to exceed 2**31-1. > The fixup are trivial. The internal representation of the number must be Long, and user shall be urged to upgrade to new release. > I have attached a fixed version of the MultipleHiloPertablegenerator.java where the generated sequencenumber are treated as a long. I have allso tested my modified version and verified that the sequence-generation part on a Oracle system works as expected, which is that the generated sequence actually can exceed 2**31-1. > (I have not tested the schema-generate-part, since this is not critical for user.) -- 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

16 years, 11 months

1
0
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues July 2007