October 2007 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HSEARCH-125) Add support for fields declared by interface or unmapped superclass

by Igor Stroh (JIRA)

Add support for fields declared by interface or unmapped superclass ------------------------------------------------------------------- Key: HSEARCH-125 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-125 Project: Hibernate Search Issue Type: Improvement Components: engine, mapping Affects Versions: 3.0.0.GA Reporter: Igor Stroh Priority: Minor Attachments: IndexedTarget.patch If an @IndexedEmbedded field is delcared by an interface or a unmapped superclass, there is no way hibernate-search can resolve the concrete class (compare to org.hibernate.annotations.Target or the targetEntity parameter for @*To* annotations). The attached patch solves this issue by introducing a IndexedTarget annotation which, much like @Target, expects the mapped class as its single parameter. See test/org/hibernate/search/test/embedded/ changes for a simple example. This issue was first exmplained in http://forum.hibernate.org/viewtopic.php?p=2366118 -- 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, 9 months

3
6
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-130) Should provide better log infos (on the indexBase parameter for the FSDirectoryProvider)

by Eric Perrocheau (JIRA)

Should provide better log infos (on the indexBase parameter for the FSDirectoryProvider) ---------------------------------------------------------------------------------------- Key: HSEARCH-130 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-130 Project: Hibernate Search Issue Type: Improvement Components: directory provider Affects Versions: 3.0.0.GA Reporter: Eric Perrocheau Priority: Minor When tracking bugs due to invalid directories names for the FSDirectoryProvider, it could be nice if the logs did inform more on Hibernate Search behaviour, or help highlight some problem. E.g., if the indexes already exist on disk, under windows vista, and we provide the directory name with erroneous trailing spaces in the configuration file : Hibernate Search run half well : the only problem is that it clears the old indexes on initializing the FSDirectoryProvider since it didn't find the directory with the trailing spaces. After that, it doesn't seem to mind the wrong directory name since it finds and uses the good one. Is suppose we could expect Hibernate Search to tell that something is happening and why, in fact, without having to go in the code with the debugger to find that the trailing spaces are sometimes a problem and sometimes not. (this improvement was asked for on http://forum.hibernate.org/viewtopic.php?t=980567 ) -- 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, 9 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-126) Better diagnostic when Search index directory cannot be opened

by Ian (JIRA)

Better diagnostic when Search index directory cannot be opened -------------------------------------------------------------- Key: HSEARCH-126 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-126 Project: Hibernate Search Issue Type: Patch Affects Versions: 3.1.0 Environment: Found in version deployed inside JBoss-Seam 2.0.0.CR2, but affects more Reporter: Ian Priority: Minor Attachments: DirectoryProviderHelper.diff When Search cannot create the index directory, the message in the Exception thrown by o.h.s.util.DirectoryProviderHelper.java contains the path as entered by the original user; it is often the case that this will be deployed inside an application server and the user will not know the correct path that is in need of permissions repair because of the way e.g., JBoss-AS creates randomly named subdirectories under e.g., server/default/deploy. This just changes the message to include the full path if the user gave an absolute path. -- 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, 9 months

2
5
0 / 0

[Hibernate-JIRA] Created: (HHH-2616) No event is fired on Collection recreate/remove/update action

by Emmanuel Bernard (JIRA)

No event is fired on Collection recreate/remove/update action ------------------------------------------------------------- Key: HHH-2616 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2616 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.4 Reporter: Emmanuel Bernard There is no way today to know if a collection has been updated (in the generic sense of it) managedEntity.getCollection().add(object) fires no event. Seems to me that it should fire Pre/PostUpdateEvent. Because of PostUpdateEvent signature we might need a PostUpdateCollectionEvent (Update meaning Update/Create/Delete) -- 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, 9 months

5
7
0 / 0

[Hibernate-JIRA] Created: (HV-12) Check Validator

by Anderson Souza (JIRA)

Check Validator --------------- Key: HV-12 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-12 Project: Hibernate Validator Issue Type: Patch Components: validators Affects Versions: 3.0.0.ga Reporter: Anderson Souza Attachments: patch.zip It's a new validator with the same behavior of database check constraints. I think it will be very useful. I had to apply a small change to the DefaultMessageInterpolator class, just to permit the array values to be interpolated on the generated message. -- 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, 9 months

2
1
0 / 0

[Hibernate-JIRA] Created: (HHH-2588) Incorrect database updates with "generated" fields in record

by Frits Jalvingh (JIRA)

Incorrect database updates with "generated" fields in record ------------------------------------------------------------ Key: HHH-2588 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2588 Project: Hibernate3 Issue Type: Bug Components: core Affects Versions: 3.2.3, 3.2.0.ga Environment: Tested with Hibernate 3.2.3 and 3.2.0GA, Oracle 10gR2, Linux, Java 5. Reporter: Frits Jalvingh I have a single POJO (UserGroup) which is based on a superclass which defines a number of properties as @Generated(GenerationTime.INSERT); amongst others tcn and ros_id. These properties are defined as "not null" in the database, and are filled in by an insert database trigger. When I create a new instance and do this: -------------------- Transaction tr = getSession().beginTransaction(); UserGroup ug = new UserGroup(); ug.setType(UserGroupType.PLN); ug.setName(name); ug.setDescription(desc); getSession().save(ug); // persist() exhibits the same problem... ug.setGroupEmail("jaja(a)nono.com"); tr.commit(); -------------------- I get a database exception: ORA-01407: cannot update ("TEST"."CRM_GROUPS"."ROS_ID") to NULL When I look at the persister's logging I see something very wrong happening: -------------------- DEBUG - commit DEBUG - automatically flushing session DEBUG - flushing session DEBUG - processing flush-time cascades DEBUG - dirty checking collections DEBUG - Flushing entities and processing referenced collections DEBUG - nl.itris.viewpoint.db.crm.UserGroup.groupEmail is dirty DEBUG - nl.itris.viewpoint.db.crm.UserGroup.memberMutable is dirty DEBUG - Updating entity: [nl.itris.viewpoint.db.crm.UserGroup#1150000159] DEBUG - nl.itris.viewpoint.db.crm.UserGroup.groupEmail is dirty DEBUG - nl.itris.viewpoint.db.crm.UserGroup.memberMutable is dirty DEBUG - Collection found: [nl.itris.viewpoint.db.crm.UserGroup.memberList#1150000159], was: [<unreferenced>] (initialized) DEBUG - Processing unreferenced collections DEBUG - Scheduling collection removes/(re)creates/updates DEBUG - Flushed: 1 insertions, 1 updates, 0 deletions to 1 objects DEBUG - Flushed: 1 (re)creations, 0 updates, 0 removals to 1 collections DEBUG - listing entities: DEBUG - nl.itris.viewpoint.db.crm.UserGroup{groupEmail=jal(a)etc.to, memberList=[], type=PLN, tcn=null, logTime=null, logModule=null, id=1150000159, organisationId=null, groupLeader=null, description=test2, memberMutable=null, logDate=null, name=test2, logUser=null} DEBUG - executing flush DEBUG - registering flush begin DEBUG - Inserting entity: [nl.itris.viewpoint.db.crm.UserGroup#1150000159] DEBUG - about to open PreparedStatement (open PreparedStatements: 0, globally: 0) DEBUG - insert into CRM_GROUPS (CGP_DESCRIPTION, CGP_GROUPEMAIL, CST_ID, CGP_MEMBER_MUTABLE, CGP_NAME, CGP_TYPE, CGP_ID) values (?, ?, ?, ?, ?, ?, ?) DEBUG - preparing statement DEBUG - Dehydrating entity: [nl.itris.viewpoint.db.crm.UserGroup#1150000159] DEBUG - binding 'test2' to parameter: 1 DEBUG - binding null to parameter: 2 DEBUG - binding null to parameter: 3 DEBUG - binding 'test2' to parameter: 5 DEBUG - Binding 'PLN' to parameter: 6 DEBUG - binding '1150000159' to parameter: 7 DEBUG - Executing batch size: 1 DEBUG - success of batch update unknown: 0 DEBUG - about to close PreparedStatement (open PreparedStatements: 1, globally: 1) DEBUG - closing statement DEBUG - about to open PreparedStatement (open PreparedStatements: 0, globally: 0) DEBUG - select usergroup_.LOG_DATE as LOG2_74_, usergroup_.LOG_MODULE as LOG3_74_, usergroup_.LOG_TIME as LOG4_74_, usergroup_.LOG_USER as LOG5_74_, usergroup_.TCN as TCN74_, usergroup_.ROS_ID as ROS7_74_ from CRM_GROUPS usergroup_ where usergroup_.CGP_ID=? DEBUG - preparing statement DEBUG - binding '1150000159' to parameter: 1 DEBUG - about to open ResultSet (open ResultSets: 0, globally: 0) DEBUG - returning '2007-04-26 00:00:00' as column: LOG2_74_ DEBUG - returning null as column: LOG3_74_ DEBUG - returning '14:28:04' as column: LOG4_74_ DEBUG - returning 'VPC' as column: LOG5_74_ DEBUG - returning '310525020' as column: TCN74_ DEBUG - returning '1500' as column: ROS7_74_ DEBUG - about to close ResultSet (open ResultSets: 1, globally: 1) DEBUG - Updating entity: [nl.itris.viewpoint.db.crm.UserGroup#1150000159] DEBUG - about to open PreparedStatement (open PreparedStatements: 1, globally: 1) DEBUG - update CRM_GROUPS set TCN=?, ROS_ID=?, CGP_DESCRIPTION=?, CGP_GROUPEMAIL=?, CST_ID=?, CGP_MEMBER_MUTABLE=?, CGP_NAME=?, CGP_TYPE=? where CGP_ID=? DEBUG - preparing statement DEBUG - Dehydrating entity: [nl.itris.viewpoint.db.crm.UserGroup#1150000159] DEBUG - binding null to parameter: 1 DEBUG - binding null to parameter: 2 DEBUG - binding 'test2' to parameter: 3 DEBUG - binding 'jal(a)etc.to' to parameter: 4 DEBUG - binding null to parameter: 5 DEBUG - binding 'test2' to parameter: 7 DEBUG - Binding 'PLN' to parameter: 8 DEBUG - binding '1150000159' to parameter: 9 DEBUG - Executing batch size: 1 DEBUG - about to close PreparedStatement (open PreparedStatements: 2, globally: 2) DEBUG - closing statement DEBUG - Could not execute JDBC batch update [update CRM_GROUPS set TCN=?, ROS_ID=?, CGP_DESCRIPTION=?, CGP_GROUPEMAIL=?, CST_ID=?, CGP_MEMBER_MUTABLE=?, CGP_NAME=?, CGP_TYPE=? where CGP_ID=?] to.etc.dbpool.BetterSQLException: java.sql.BatchUpdateException: ORA-01407: cannot update ("VIEWPOINT"."CRM_GROUPS"."ROS_ID") to NULL SQL: update CRM_GROUPS set TCN=?, ROS_ID=?, CGP_DESCRIPTION=?, CGP_GROUPEMAIL=?, CST_ID=?, CGP_MEMBER_MUTABLE=?, CGP_NAME=?, CGP_TYPE=? where CGP_ID=? Parameters: #1:[null] #2:[null] #3:java.lang.String:test2 #4:java.lang.String:jal@etc.to #5:[null] #6:java.lang.String:N #7:java.lang.String:test2 #8:java.lang.String:PLN #9:java.lang.Long:1150000159 at to.etc.dbpool.PreparedStatementProxy.wrap(PreparedStatementProxy.java:68) at to.etc.dbpool.StatementProxy.executeBatch(StatementProxy.java:176) at org.hibernate.jdbc.BatchingBatcher.doExecuteBatch(BatchingBatcher.java:48) at org.hibernate.jdbc.AbstractBatcher.executeBatch(AbstractBatcher.java:246) at org.hibernate.persister.entity.AbstractEntityPersister.processGeneratedProperties(AbstractEntityPersister.java:3691) at org.hibernate.persister.entity.AbstractEntityPersister.processUpdateGeneratedProperties(AbstractEntityPersister.java:3680) at org.hibernate.action.EntityUpdateAction.execute(EntityUpdateAction.java:124) at org.hibernate.engine.ActionQueue.execute(ActionQueue.java:248) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:232) at org.hibernate.engine.ActionQueue.executeActions(ActionQueue.java:140) at org.hibernate.event.def.AbstractFlushingEventListener.performExecutions(AbstractFlushingEventListener.java:298) at org.hibernate.event.def.DefaultFlushEventListener.onFlush(DefaultFlushEventListener.java:27) at org.hibernate.impl.SessionImpl.flush(SessionImpl.java:1000) at org.hibernate.impl.SessionImpl.managedFlush(SessionImpl.java:338) at org.hibernate.transaction.JDBCTransaction.commit(JDBCTransaction.java:106) at nl.itris.moca.ajax.Planner.updatePlanGroup(Planner.java:1717) ---------------------------------- Hibernate starts by inserting the new record correctly, and then reselects the inserted record to retrieve the changed fields correctly. But after that it does an update of that record with stale data: it sets all of the generated fields it *has* read to null, and updates the groupEmail field which for some reason was not present in the insert!? It looks like multiple versions of the same records are maintained in some way?? The problem is triggered by the existence of the "save" call *followed by* another change to the record. But the same problem occurs when other things cause an intermediary update, for instance when trying to save the data in a collection parented by UserGroup. Because this problem also occurs when I add/change elements in the UserGroup's associated GroupMember one-to-many association I am effectively unable to store a group with it's members in one transaction! In addition I noticed that the persist() call seems to check defined constraints on the record at the time persist() is called instead of the time that it gets commited. This means it can only be called when the pojo is complete which looks odd to me? I sort of understand this for save() as that is required to return the primary key but I do not understand why this is needed for persist... -- 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, 9 months

2
6
0 / 0

[Hibernate-JIRA] Created: (HHH-2384) Patch for using case-expression("case ... when ... end") in aggregate functions

by Florian Rock (JIRA)

Patch for using case-expression("case ... when ... end") in aggregate functions ------------------------------------------------------------------------------- Key: HHH-2384 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2384 Project: Hibernate3 Type: Patch Components: query-hql Versions: 3.2.2 Reporter: Florian Rock Priority: Minor Attachments: aggrcasehql.patch using a case-expression in aggregate functions causes a QuerySyntaxException.. ie.: "count(case when fubar > 0 then 1 else null end)" i changed some things in the grammar to solve this, patch is attached. -- 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, 9 months

4
3
0 / 0

[Hibernate-JIRA] Created: (ANN-621) Unable to handle JOINED stragegy when the root entity id contains a @ManyToOne

by Emmanuel Bernard (JIRA)

Unable to handle JOINED stragegy when the root entity id contains a @ManyToOne ------------------------------------------------------------------------------ Key: ANN-621 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-621 Project: Hibernate Annotations Issue Type: Bug Components: binder Affects Versions: 3.3.0.ga Reporter: Emmanuel Bernard Assignee: Emmanuel Bernard Priority: Minor Fix For: 3.3.1 -- 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, 9 months

2
3
0 / 0

[Hibernate-JIRA] Created: (HV-26) Which version of Hibernate Annotations does ClassValidator depend on?

by Steven Devijver (JIRA)

Which version of Hibernate Annotations does ClassValidator depend on? --------------------------------------------------------------------- Key: HV-26 URL: http://opensource.atlassian.com/projects/hibernate/browse/HV-26 Project: Hibernate Validator Issue Type: Bug Components: validators Affects Versions: 3.0.0.ga Reporter: Steven Devijver According to the Compatibility Matrix on the Hibernate website (http://www.hibernate.org/6.html) Hiberbate Validator 3.3.0 GA depends on Hibernate Annotations 3.3.x. The only 3.3.x release of Hibernate Annotations is 3.3.0 GA. However, the dependency in the compatibility matrix does not seem to be correct. When I load ClassValidator in my project I get this error: The type org.hibernate.annotations.common.reflection.ReflectionManager cannot be resolved. It is indirectly referenced from required .class files Version 3.3.0 GA of Hibernate Annotations however does not have the class org.hibernate.annotations.common.reflection.ReflectionManager. It does however contain org.hibernate.annotations.common.reflection.EJB3ReflectionManager. So, which version of Hibernate Annotations should be used with Hibernate Validator 3.0.0 GA? -- 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, 9 months

5
4
0 / 0

[Hibernate-JIRA] Created: (ANN-582) Joda User Types

by Martin Gilday (JIRA)

Joda User Types --------------- Key: ANN-582 URL: http://opensource.atlassian.com/projects/hibernate/browse/ANN-582 Project: Hibernate Annotations Type: New Feature Versions: 3.2.1 Reporter: Martin Gilday Attachments: jodaUserTypes.zip As discussed on the forums http://forum.hibernate.org/viewtopic.php?t=972083 here are some user types for Joda Time. It covers LocalDate, LocalDateTime and LocalTime checked against Joda 1.4. Currently it has been used with MySql4.x. It relies on using date patterns for converting the joda objects and then setting them as Strings. This should work for any database that uses the same date/time formats. One possible improvement might be to convert to java.sql.Date etc and allow JDBC to handle the setting in the DB. Although I do not know how this would affect timezones, which was the reason for using LocalXxx. -- 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, 9 months

3
2
0 / 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues October 2007