October 2010 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HSEARCH-569) duplicate identifiers on @AnalyzerDef are accepted and don't warn about the inconsistent configuration

by Sanne Grinovero (JIRA)

duplicate identifiers on @AnalyzerDef are accepted and don't warn about the inconsistent configuration ------------------------------------------------------------------------------------------------------ Key: HSEARCH-569 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-569 Project: Hibernate Search Issue Type: Improvement Reporter: Sanne Grinovero Priority: Minor Fix For: 3.3.0 Some confusion on the forums about this: https://forum.hibernate.org/posting.php?mode=reply&f=9&t=1005878 -- 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, 8 months

3
3
0 / 0

[Hibernate-JIRA] Created: (HHH-5691) JPA with Hibernate 3 - ManyToMany-Stack overflow and Multiple bag errors

by Suyash Kaulgud (JIRA)

JPA with Hibernate 3 - ManyToMany-Stack overflow and Multiple bag errors ------------------------------------------------------------------------ Key: HHH-5691 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5691 Project: Hibernate Core Issue Type: Bug Components: core Affects Versions: 3.5.1 Environment: Spring 3.0.3 Hibernate-core : 3.5.1-Final Hibernate-annotations : 3.5.1-Final hibernate-common-annotations : 3.2.0-Final hibernate-entitymanager : 3.5.1-Final Mysql database Junit 4 Reporter: Suyash Kaulgud Attachments: fms-web.zip I am facing issues while retrieving data for entities having bi-directional many-to-many relationship. If I use List for storing entities, I get unable to fetch multiple bags simultaneously error. If i change my code to use Set, I get stackoverflow error. Details : Spring 3.0.3 Hibernate-core : 3.5.1-Final Hibernate-annotations : 3.5.1-Final hibernate-common-annotations : 3.2.0-Final hibernate-entitymanager : 3.5.1-Final Mysql database Junit 4 User has Many Bank Accounts; Bank Account can have many users User.java @ManyToMany(fetch = FetchType.EAGER, mappedBy="user") private List<BankAccount> bankAccounts = new ArrayList<BankAccount>(); BankAccount.java @ManyToMany(fetch = FetchType.EAGER) @JoinTable(name = "user_bankaccount", joinColumns = @JoinColumn(name="bank_account_id"), inverseJoinColumns = @JoinColumn(name = "user_id") ) private List<User> user = new ArrayList<User>(); DB Tables Users user_id PK Bankaccount bank_account_id PK user_bankaccount bank_account_id PK ( references bankaccount.bank_account_id ) user_id PK ( references user.user_id ) issues when I try to get all the users data (getAllUsers) using a JUnit test case, I get unable to fetch multiple bags simultaneously error. If I use Set and HashSet instead of List and ArrayList respectively, I get stackoverflow error. -- 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, 8 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HHH-5631) Fix warnings reported by Maven 3

by Julien HENRY (JIRA)

Fix warnings reported by Maven 3 -------------------------------- Key: HHH-5631 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5631 Project: Hibernate Core Issue Type: Improvement Components: build Affects Versions: 3.6.x Reporter: Julien HENRY Priority: Trivial Maven 3 display some warnings about deprecated properties and bad practices. I have fixed them in a git branch. -- 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, 8 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-3144) Final methods preclude some useful Hibernate extensions

by Ali Ibrahim (JIRA)

Final methods preclude some useful Hibernate extensions ------------------------------------------------------- Key: HHH-3144 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-3144 Project: Hibernate3 Issue Type: Improvement Components: core Affects Versions: 3.2.6 Reporter: Ali Ibrahim Priority: Minor The following methods are final: AbstractPersistentCollection#read, AbstractPersistentCollection#write, AbstractLazyInitializer#initialize. It can be useful to override these methods. Fix is to make them protected. -- 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, 8 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-612) Be able to override default MassIndexerProgressMonitor with custom implementations

by Sanne Grinovero (JIRA)

Be able to override default MassIndexerProgressMonitor with custom implementations ---------------------------------------------------------------------------------- Key: HSEARCH-612 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-612 Project: Hibernate Search Issue Type: New Feature Reporter: Sanne Grinovero Fix For: 3.4.0 This is already mentioned in the javadocs of org.hibernate.search.batchindexing.MassIndexerProgressMonitor, make sure the API got stable before implementing this. -- 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, 8 months

1
2
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-613) Automatic archetype install and deploy

by Hardy Ferentschik (JIRA)

Automatic archetype install and deploy -------------------------------------- Key: HSEARCH-613 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-613 Project: Hibernate Search Issue Type: Task Components: build Affects Versions: 3.3.0.Beta2 Reporter: Hardy Ferentschik Assignee: Hardy Ferentschik Fix For: 3.3.0.Beta3 Currently during a _mvn deploy_ the archetype gets created, but not installed or deployed. After running _mvn deploy_ from the top level directory you still have to do a deploy from {{hibernate-search-archetype/target/generated-sources/archetype}}. If the archetype generation would be part of the main deploy command it would simplify the build. -- 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, 8 months

1
1
0 / 0

[Hibernate-JIRA] Commented: (HHH-1914) session.merge(persistentEntity) fails on unmodifiable collections

by Maxim Frolov (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-1914?page=c... ] Maxim Frolov commented on HHH-1914: ----------------------------------- The same issue with EclipseLink as Persistence Provider in validation context (using Hibernate as JSR303 validation provider): I did the following: @Entity @Entity RootEntity <----> LeafEntity 1 * RootEntity root = new RootEntity() merge(root) LeafEntity leaf = new LeafEntity() leaf.setInvalidProperty() leaf.setRoot(root) root.addLeaf(leaf) merge(leaf) commit() After commit() I have received in @PreSave-Listener a copy of root entity with empty collection of leafs (expected: non-empty collection) and validated that copy of root entity. Validation has failed as expected but the ConstraintViolation was not correct: both RootBean und LeafBean were the same leaf entity (expected: root entity in RootBean, leaf entity in LeafBean). > session.merge(persistentEntity) fails on unmodifiable collections > ----------------------------------------------------------------- > > Key: HHH-1914 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-1914 > Project: Hibernate Core > Issue Type: Bug > Components: core > Reporter: Emmanuel Bernard > Priority: Minor > > Cat cat = new Cat(); > cat.setId( new CatPk() ); > cat.getId().setName( "titi" ); > cat.getId().setThoroughbred( "unknown" ); > Set<Woman> women = new HashSet<Woman>(); > Woman woman = new Woman(); > woman.setId( new WomanPk() ); > woman.getId().setFirstName( "Lady" ); > woman.getId().setLastName( "McBeth" ); > women.add( woman ); > cat.setHumanContacts( Collections.unmodifiableSet( women ) ); > Set<Cat> cats = new HashSet<Cat>(); > cats.add( cat ); > woman.setCats( Collections.unmodifiableSet(cats) ); > s.persist( cat ); > s.persist( woman ); > tx.commit(); > s.merge( woman ); > During merge, the entity is copied into itself (?) > defaultmergeeventlistener.entityIsPersistent() => copyValues(persister, entity, entity, source, copyCache); > java.lang.UnsupportedOperationException > at java.util.Collections$UnmodifiableCollection.clear(Collections.java:1037) > at org.hibernate.collection.PersistentSet.clear(PersistentSet.java:247) > at org.hibernate.type.CollectionType.replaceElements(CollectionType.java:404) > at org.hibernate.type.CollectionType.replace(CollectionType.java:449) > at org.hibernate.type.TypeFactory.replace(TypeFactory.java:437) > at org.hibernate.event.def.DefaultMergeEventListener.copyValues(DefaultMergeEventListener.java:282) > at org.hibernate.event.def.DefaultMergeEventListener.entityIsPersistent(DefaultMergeEventListener.java:132) > at org.hibernate.event.def.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:105) > at org.hibernate.event.def.DefaultMergeEventListener.onMerge(DefaultMergeEventListener.java:51) > at org.hibernate.impl.SessionImpl.fireMerge(SessionImpl.java:677) > at org.hibernate.impl.SessionImpl.merge(SessionImpl.java:661) > at org.hibernate.impl.SessionImpl.merge(SessionImpl.java:665) > at org.hibernate.test.annotations.manytomany.ManyToManyTest.testUnmodifiableCollection(ManyToManyTest.java:102) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) > at org.hibernate.test.annotations.TestCase.runTest(TestCase.java:67) > at com.intellij.rt.execution.junit2.JUnitStarter.main(JUnitStarter.java:32) > 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) > What is the reason for that? The spec says that > "If X is a managed entity, it is ignored by the merge operation" -- 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, 8 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-5168) DB2Dialect generates CROSS JOINs which aren't supported

by Grzegorz Olędzki (JIRA)

DB2Dialect generates CROSS JOINs which aren't supported ------------------------------------------------------- Key: HHH-5168 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5168 Project: Hibernate Core Issue Type: Bug Affects Versions: 3.5.0-Final Environment: Hibernate 3.5.0-Final, using hibernate-jpa-2.0-api-1.0.0.Final.jar, DB2/NT SQL09013 Reporter: Grzegorz Olędzki When executing a simple JPQL query: {code} SELECT st FROM ScheduledTask st WHERE (NOT st.status = 'COMPLETED') AND st.active = TRUE AND st.task.group = :group {code} Hibernate generates the following SQL query: {code} select scheduledt0_.QSID as col_0_0_ from SCHSCHEDTASK_QS scheduledt0_ cross join SCHTASK_QT task1_ where scheduledt0_.QTID=task1_.QTID and scheduledt0_.QSSTATUS<>'COMPLETED' and scheduledt0_.QSACTIVE=1 and task1_.QTGROUP=? {code} which crashes with: {code} 2010-04-28 10:14:18,551 WARN [org.hibernate.util.JDBCExceptionReporter]/[org.hibernate.util.JDBCExceptionReporter] SQL Error: -104, SQLState: 42601 2010-04-28 10:14:18,552 ERROR [org.hibernate.util.JDBCExceptionReporter]/[org.hibernate.util.JDBCExceptionReporter] DB2 SQL error: SQLCODE: -104, SQLSTATE: 42601, SQLERRMC: cross;TASK_QS scheduledt0_;<space> 2010-04-28 10:14:18,552 WARN [org.hibernate.util.JDBCExceptionReporter]/[org.hibernate.util.JDBCExceptionReporter] SQL Error: -727, SQLState: 56098 2010-04-28 10:14:18,553 ERROR [org.hibernate.util.JDBCExceptionReporter]/[org.hibernate.util.JDBCExceptionReporter] DB2 SQL error: SQLCODE: -727, SQLSTATE: 56098, SQLERRMC: 2;-104;42601;cross|TASK_QS scheduledt0_|<space> 2010-04-28 10:14:18,554 WARN [org.hibernate.util.JDBCExceptionReporter]/[org.hibernate.util.JDBCExceptionReporter] SQL Error: -727, SQLState: 56098 2010-04-28 10:14:18,554 ERROR [org.hibernate.util.JDBCExceptionReporter]/[org.hibernate.util.JDBCExceptionReporter] DB2 SQL error: SQLCODE: -727, SQLSTATE: 56098, SQLERRMC: 2;-104;42601;cross|TASK_QS scheduledt0_|<space> {code} The very same JPQL query works on MySQL database (the actual SQL query uses CROSS JOIN too). When trying to run the same SQL on DB2 manually in a database client the error message is the same (-104, 42601). A subtle change in the query, i.e. replacing CROSS JOIN with a comma (,) seems to fix the problem - both manually and using Hibernate-based application. Using the following DB2Dialect seems to help: {code} public class DB2Dialect extends org.hibernate.dialect.DB2Dialect { @Override public String getCrossJoinSeparator() { return ", "; } } {code} -- 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, 8 months

5
9
0 / 0

[Hibernate-JIRA] Commented: (HHH-468) MysqlDialect incorrectly maps java.lang.Boolean to SQL BIT

by Nikita D (JIRA)

[ http://opensource.atlassian.com/projects/hibernate/browse/HHH-468?page=co... ] Nikita D commented on HHH-468: ------------------------------ Perhaps the root problem is in org.hibernate.type.BooleanType, whose sqlType() method returns java.sql.Types.BIT. Because of this, for a field whose type is a java boolean/Boolean, the dialect class is actually asked to map a java.sql.Types.BIT to its String column type. The MySQL dialect returns "bit" as the String for java.sql.Types.BIT, but I think this actually makes sense since MySQL supports both BIT and BOOLEAN (see http://dev.mysql.com/doc/refman/5.0/en/numeric-type-overview.html). java.sql.Types also defines both BIT and BOOLEAN. >From what I understand, here is how the mapping happens right now: * The MySQL dialect registers the column type mapping registerColumnType( Types.BIT, "bit" ). It doesn't register anything for java.sql.Types.BOOLEAN. * When generating the DDL, SchemaExport calls Configuration.generateSchemaCreationScript(). For each column, the SQL type is retrieved using Column.getSqlType(). * Column.getSqlType() gets the java.sql.Types type from the org.hibernate.type.Type of the Column. This is where the org.hibernate.type.BooleanType returns java.sql.Types.BIT. * The dialect's method getTypeName() is invoked with the java.sql.Types type in order to get the string representation for the JDBC SQL type code. So to me, it seems that the issue is the mapping from the java boolean/Boolean to the java.sql.Types type, not in the dialect's mapping of the java.sql.Types type to its String representation. If the MySQL dialect registered the type java.sql.Types.BOOLEAN, and if org.hibernate.type.BooleanType returned java.sql.Types.BOOLEAN, booleans would be mapped correctly. The problem is, I am not sure what the repercussions are of changing org.hibernate.type.BooleanType.sqlType() or if there are particular reasons for it to be implemented the way it is right now. > MysqlDialect incorrectly maps java.lang.Boolean to SQL BIT > ---------------------------------------------------------- > > Key: HHH-468 > URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-468 > Project: Hibernate Core > Issue Type: Bug > Affects Versions: 3.0.3 > Environment: Hibernate 3.0, MySQL. > Reporter: Mark Matthews > Assignee: Scott Marlow > > I didn't track down how java.lang.Boolean gets mapped to Types.BIT in hibernate, but you probably _don't_ want to map to "bit" like you do in MysqlDialect. > "bit", according to SQL99 (it's not in the core standard, and the type was actually dropped for sql2k3) is a bitfield, not a boolean value. You can of course define a bit(1), but it is technically more correct for java.lang.Boolean to map to a SQL BOOLEAN for MySQL since we support a BOOLEAN and a BIT. > It looks like the JDBC-3.0 guys ignored what the standard said, because in reality you'd want BIT to map to something like byte[], or java.util.BitSet if you were tracking how the SQL standard defines BIT. > I'm guessing you probably want to map to "boolean", which the JDBC driver will automagically convert for you, as it silently maps to TINYINT(1) on the server side. -- 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, 8 months

1
0
0 / 0

[Hibernate-JIRA] Created: (HHH-5490) dirty data be inserted into 2L cache

by Strong Liu (JIRA)

dirty data be inserted into 2L cache ------------------------------------- Key: HHH-5490 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-5490 Project: Hibernate Core Issue Type: Bug Components: caching (L2) Affects Versions: 3.6.0.Beta3, 3.5.5 Reporter: Strong Liu {code} public void testInsertWithRefresh() { getSessions().getCache().evictEntityRegions(); getSessions().getStatistics().clear(); Session s = openSession(); s.beginTransaction(); Item item = new Item(); item.setName("stliu"); s.save(item); s.flush(); s.refresh(item); s.getTransaction().rollback(); s.close(); Map cacheMap = getSessions().getStatistics() .getSecondLevelCacheStatistics("item").getEntries(); assertEquals(0, cacheMap.size()); s = openSession(); s.beginTransaction(); item = (Item)s.get(Item.class, item.getId()); s.getTransaction().commit(); s.close(); assertNull("it should be null", item); } {code} see above test case, since the insertion is rollbacked, so, there is no that row in the DB, but you can see the null assertion will fail due to the dirty data be inserted into the 2l cache after refresh operation. -- 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, 8 months

3
8
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues October 2010