February 2010 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HV-289) Add requirements section to online manual about usage of Validator in JDK 5 and 6

by Hardy Ferentschik (JIRA)

Add requirements section to online manual about usage of Validator in JDK 5 and 6 --------------------------------------------------------------------------------- Key: HV-289 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-289 Project: Hibernate Validator Issue Type: Task Components: documentation Affects Versions: 4.0.2.GA Reporter: Hardy Ferentschik Assignee: Hardy Ferentschik Fix For: 4.1.0 In Java 5 one has to add the JAXB dependencies. -- 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, 10 months

1
1
0 / 0

[Hibernate-JIRA] Created: (HV-282) Create CreditCardValidator

by Hardy Ferentschik (JIRA)

Create CreditCardValidator -------------------------- Key: HV-282 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-282 Project: Hibernate Validator Issue Type: Task Components: validators Reporter: Hardy Ferentschik Assignee: Hardy Ferentschik Fix For: 4.0.2.GA Using the legacy CreditCardValidator as base create a JSR-303 compatible credit card validator -- 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, 10 months

1
2
0 / 0

[Hibernate-JIRA] Created: (HHH-2661) Second-level cache is used after Session.setCacheMode(CacheMode.IGNORE)

by Anders Wallgren (JIRA)

Second-level cache is used after Session.setCacheMode(CacheMode.IGNORE) ----------------------------------------------------------------------- Key: HHH-2661 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2661 Project: Hibernate3 Issue Type: Bug Components: caching (L2) Affects Versions: 3.2.4.sp1 Environment: Windows Vista MySQL 5.0 Reporter: Anders Wallgren I'm doing some bulk importing and want to disable the L2 cache, so I call Session.setCacheMode(CacheMode.IGNORE) before doing any work. However, the entities I'm creating still end up in the cache. It seems that org.hibernate.action.CollectionAction isn't doing the correct check to determine when to cache -- it only check for the existence of a configured cache, but doesn't check whether caching is enabled in the session. For example, from CollectionAction.beforeExecutions: public final void beforeExecutions() throws CacheException { // we need to obtain the lock before any actions are // executed, since this may be an inverse="true" // bidirectional association and it is one of the // earlier entity actions which actually updates // the database (this action is resposible for // second-level cache invalidation only) if ( persister.hasCache() ) { final CacheKey ck = new CacheKey( key, persister.getKeyType(), persister.getRole(), session.getEntityMode(), session.getFactory() ); lock = persister.getCache().lock(ck, null); } } Shouldn't "if ( persister.hasCache() )" be persistence.hasCache && getSession.getCacheMode.isPutEnabled(), or something along those lines? -- 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, 10 months

3
3
0 / 0

[Hibernate-JIRA] Created: (HV-229) @Url needs to be added

by Ken Egervari (JIRA)

@Url needs to be added ---------------------- Key: HV-229 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-229 Project: Hibernate Validator Issue Type: New Feature Affects Versions: 3.1.0.GA Reporter: Ken Egervari It would be nice to have a @Url constraint. This is a very common use-case. The regular expression itself is tedious to write - there are tons of versions online. There could be options to allow for mailto: and others, to make it stronger or looser as needed by the application. However, a basic one would be a great addition to the library as lots and lots of users will need this to be sure. Thanks! -- 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, 10 months

3
10
0 / 0

[Hibernate-JIRA] Created: (HHH-4933) Write documentation on JPA 2 annotations

by Emmanuel Bernard (JIRA)

Write documentation on JPA 2 annotations ---------------------------------------- Key: HHH-4933 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4933 Project: Hibernate Core Issue Type: Task Components: annotations Reporter: Emmanuel Bernard Assignee: Emmanuel Bernard Fix For: 3.5.x -- 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, 10 months

1
3
0 / 0

[Hibernate-JIRA] Created: (HHH-3899) Inconsistencies when processing changes to read-only and immutable entities

by Gail Badner (JIRA)

Inconsistencies when processing changes to read-only and immutable entities --------------------------------------------------------------------------- Key: HHH-3899 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3899 Project: Hibernate Core Issue Type: Bug Reporter: Gail Badner I've noticed that there are inconsistencies when read-only and immutable entities are modified. I've added some unit tests to org.hibernate.test.immutable.ImmutableTest and created org.hibernate.test.readonly.ReadOnlyVersionedNodesTest which show the inconsistencies. The same behavior is seen in Branch_3_2, Branch_3_3, and trunk. The inconsistencies in org.hibernate.test.immutable.ImmutableTest are: ImmutableTest.testImmutable(): If an immutable entity with an immutable collection is associated with the session, an addition to the immutable collection is ignored ImmutableTest.testImmutableCollectionWithUpdate: If Session.update() is used to associate an immutable entity with an addition made to its immutable collection, then Hibernate detects that the reassociated entity has a dirty collection and HibernateException is thrown ImmutableTest.testImmutableCollectionWithMerge: If Session.merge() is used to associate an immutable entity with an addition made to its immutable collection, then, later when the transaction is committed, Hibernate detects that an immutable collection was changed and HibernateException is thrown The inconsistencies in org.hibernate.test.readonly.ReadOnlyVersionedNodesTest are: ReadOnlyVersionedNodesTest.testAddNewChildToReadOnlyParent(): If a read-only entity is associated with the session and a new child entity is added to collection, the new child entity is not persisted when the transaction is committed ReadOnlyVersionedNodesTest.testUpdateParentWithNewChildCommitWithReadOnlyParent(): ReadOnlyVersionedNodesTest.testMergeDetachedParentWithNewChildCommitWithReadOnlyParent(): ReadOnlyVersionedNodesTest.testGetParentMakeReadOnlyThenMergeDetachedParentWithNewChildC(): If Session.merge() or Session.update() is used to associate a parent entity with a new child entity in its collection, and that parent entity is made read-only, then, later when the transaction is committed, the new child entity is persisted and it is associated with the parent ReadOnlyVersionedNodesTest.testAddNewParentToReadOnlyChild(): If a read-only entity is associated with the session and a new parent entity is assigned, the new parent entity is not persisted when the transaction is committed ReadOnlyVersionedNodesTest.testUpdateChildWithNewParentCommitWithReadOnlyChild(): If Session.update() is used to associate a child entity with a new parent entity, and the child entity is made read-only, later, when the transaction is committed, the new parent entity is persisted, but it is not associated with the child ReadOnlyVersionedNodesTest.testMergeDetachedChildWithNewParentCommitWithReadOnlyChild(): ReadOnlyVersionedNodesTest.testGetChildMakeReadOnlyThenMergeDetachedChildWithNewParent(): If Session.merge() is used to associate a child entity with a new parent entity, and the child entity is made read-only, later, when the transaction is committed, the new parent entity is persisted, but it is not associated with the child; in addition the version on the parent is incremented. If any of these results appear to be due to a bug, the test name should be changed to end in FailureExpected until the bug is fixed. -- 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, 10 months

1
2
0 / 0

[Hibernate-JIRA] Created: (HHH-4958) Immutable entity snapshot is retained after insert

by Gail Badner (JIRA)

Immutable entity snapshot is retained after insert -------------------------------------------------- Key: HHH-4958 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4958 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.5.0-CR-2 Reporter: Gail Badner Assignee: Gail Badner Fix For: 3.5.0.Next The "loaded state" is put in the EntityEntry when an immutable entity is added to the session via AbstractSaveEventListener.performSaveOrReplicate(), which is used by Session.persist(), Session.save(), and Session.saveOrUpdate(). The loaded state is not removed, even after flushing the session. It should be removed as soon as it is no longer needed. I am investigating whether it is ever needed. If not, then it shouldn't be put in the EntityEntry in the first place. -- 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, 10 months

1
2
0 / 0

[Hibernate-JIRA] Created: (HHH-4931) two tests in org.hibernate.test.legacy.MultiTableTest fail on Ingres

by Strong Liu (JIRA)

two tests in org.hibernate.test.legacy.MultiTableTest fail on Ingres -------------------------------------------------------------------- Key: HHH-4931 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4931 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.5.0-CR-1 Environment: ingres 9.3 Reporter: Strong Liu Assignee: Strong Liu testMultiTable(org.hibernate.test.legacy.MultiTableTest) testMultiTableGeneratedId(org.hibernate.test.legacy.MultiTableTest) ------------------------- 20:37:55,892 WARN JDBCExceptionReporter:100 - SQL Error: 2925, SQLState: 5000A 20:37:55,893 ERROR JDBCExceptionReporter:101 - SELECT: FOR UPDATE clause found in non-updatable SELECT statement. May not use set function, GROUP, HAVING, DISTINCT, UNION, ORDER or more than one variable in the FROM clause, at the outermost query level. 20:37:55,895 INFO DefaultLoadEventListener:160 - Error performing load command org.hibernate.exception.GenericJDBCException: could not load an entity: [org.hibernate.test.legacy.Top#1] at org.hibernate.exception.SQLStateConverter.handledNonSpecificException(SQLStateConverter.java:132) at org.hibernate.exception.SQLStateConverter.convert(SQLStateConverter.java:120) at org.hibernate.exception.JDBCExceptionHelper.convert(JDBCExceptionHelper.java:66) at org.hibernate.loader.Loader.loadEntity(Loader.java:1921) at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:71) at org.hibernate.loader.entity.AbstractEntityLoader.load(AbstractEntityLoader.java:65) at org.hibernate.persister.entity.AbstractEntityPersister.load(AbstractEntityPersister.java:3212) at org.hibernate.event.def.DefaultLoadEventListener.loadFromDatasource(DefaultLoadEventListener.java:496) at org.hibernate.event.def.DefaultLoadEventListener.doLoad(DefaultLoadEventListener.java:477) at org.hibernate.event.def.DefaultLoadEventListener.load(DefaultLoadEventListener.java:227) at org.hibernate.event.def.DefaultLoadEventListener.lockAndLoad(DefaultLoadEventListener.java:403) at org.hibernate.event.def.DefaultLoadEventListener.onLoad(DefaultLoadEventListener.java:155) at org.hibernate.impl.SessionImpl.fireLoad(SessionImpl.java:1080) at org.hibernate.impl.SessionImpl.load(SessionImpl.java:1045) at org.hibernate.impl.SessionImpl.load(SessionImpl.java:1036) at org.hibernate.test.legacy.MultiTableTest.testMultiTable(MultiTableTest.java:343) 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 junit.framework.TestCase.runTest(TestCase.java:154) at org.hibernate.junit.functional.FunctionalTestCase.runTest(FunctionalTestCase.java:125) at junit.framework.TestCase.runBare(TestCase.java:127) at org.hibernate.junit.UnitTestCase.runBare(UnitTestCase.java:63) 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 org.eclipse.jdt.internal.junit.runner.junit3.JUnit3TestReference.run(JUnit3TestReference.java:130) at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) Caused by: com.ingres.gcf.util.SqlEx: SELECT: FOR UPDATE clause found in non-updatable SELECT statement. May not use set function, GROUP, HAVING, DISTINCT, UNION, ORDER or more than one variable in the FROM clause, at the outermost query level. at com.ingres.gcf.jdbc.DrvObj.readError(Unknown Source) at com.ingres.gcf.jdbc.JdbcStmt.readError(Unknown Source) at com.ingres.gcf.jdbc.DrvObj.readResults(Unknown Source) at com.ingres.gcf.jdbc.JdbcStmt.readResults(Unknown Source) at com.ingres.gcf.jdbc.JdbcStmt.readResults(Unknown Source) at com.ingres.gcf.jdbc.JdbcPrep.exec(Unknown Source) at com.ingres.gcf.jdbc.JdbcPrep.executeQuery(Unknown Source) at org.hibernate.jdbc.AbstractBatcher.getResultSet(AbstractBatcher.java:208) at org.hibernate.loader.Loader.getResultSet(Loader.java:1832) at org.hibernate.loader.Loader.doQuery(Loader.java:719) at org.hibernate.loader.Loader.doQueryAndInitializeNonLazyCollections(Loader.java:271) at org.hibernate.loader.Loader.loadEntity(Loader.java:1907) ... 30 more -- 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, 10 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HHH-4780) Allow BigDecimal and BigInteger to be specified as numeric literal types

by Steve Ebersole (JIRA)

Allow BigDecimal and BigInteger to be specified as numeric literal types ------------------------------------------------------------------------ Key: HHH-4780 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-4780 Project: Hibernate Core Issue Type: Bug Components: core, query-hql Affects Versions: 3.5.0-Beta-2 Reporter: Steve Ebersole Assignee: Steve Ebersole Fix For: 3.5.0-Beta-3 Much like we currently allow with Floats ('F'), Doubles ('D') and Longs ('L') -- 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, 10 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HCANN-7) Hibernate interprets relation as embedding

by Lucius Gregory Meredith (JIRA)

Hibernate interprets relation as embedding ------------------------------------------ Key: HCANN-7 URL: http://opensource.atlassian.com/projects/hibernate/browse/HCANN-7 Project: Hibernate Commons Annotations Issue Type: Bug Affects Versions: 3.2 Environment: Mac OS X (leopard); Java 1.5 or 1.6; MySQL, HSQLDB Reporter: Lucius Gregory Meredith Hibernate interprets JPA annotations @Entity ... public class ... { ... @OneToOne @JoinColumn <MethodDecl> ...} as indication to embed the referenced entity, rather than use the key. For code sample see http://svn.biosimilarity.com/src/open/codesamples/trunk/hibernate Instructions for use: i included the target dir in the repo to speed up investigation, but you can just blow that away and build from scratch. The example is currently written to Java1.6, but also exhibits the same behavior under Java1.5. To run the example > svn co http://svn.biosimilarity.com/src/open/codesamples/trunk/hibernate ... > env PATH=<path-to-java1.6>:$PATH JAVA_HOME=<path-to-java1.6> mvn clean compile process-classes If you switch comment and decl at line 22 in src/main/java/maxb/hbex2/MySampleFuContainer.java then you see the error. The schema goes from create table lingo_production.MySampleFuContainer_table ( id_AbstractContainer varchar(255) not null, varchar(255) not null, uuid varchar(255), mysamplingmumble__idSuper varchar(255), primary key (id), unique (uuid) ); to create table lingo_production.MySampleFuContainer_table ( id_AbstractContainer varchar(255) not null, id varchar(255), mysamplingmumble_ tinyblob, uuid varchar(255), primary key (id_AbstractContainer), unique (id_AbstractContainer) ); -- 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, 10 months

2
1
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 2010