December 2007 - hibernate-issues - Jboss List Archives

[Hibernate-JIRA] Created: (HSEARCH-144) add option to keep indexer running till finished.

by Jason Eacott (JIRA)

add option to keep indexer running till finished. ------------------------------------------------- Key: HSEARCH-144 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-144 Project: Hibernate Search Issue Type: Improvement Components: engine Reporter: Jason Eacott Hi all, I've just installed and got running hibernate search - very cool! But a very minor enancement would help a lot I think, for those of us still in testing mode and not using the jms option yet. It would be very handy if there was a config option for the async executorService to stay up and complete its tasks after the app itself has been shutdown. In BatchedQueueingProcessor finalize just need to add something like this line after the executorService.shutdown();( if its set to wait in the config somewhere of course), or even better replace the params here with user defined entries from config. executorService.awaitTermination(Long.MAX_VALUE, TimeUnit.SECONDS ); The only other feature I'd like is the capability to use Spring jms instead of the jboss one out of the box. :) Great product. Cheers Jason. -- 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

18 years, 2 months

2
6
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-127) Wrong prefix for worker configurations.

by Jay Bose (JIRA)

Wrong prefix for worker configurations. --------------------------------------- Key: HSEARCH-127 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-127 Project: Hibernate Search Issue Type: Improvement Components: documentation Affects Versions: 3.0.0.GA Environment: online here - http://www.hibernate.org/hib_docs/search/reference/en/html/search-configu... Reporter: Jay Bose Priority: Minor In Table 3.2. worker configurations are all prefixed with "org.hibernate.", when it should be "hibernate.search." -- 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

18 years, 2 months

2
2
0 / 0

[Hibernate-JIRA] Created: (HSEARCH-136) CachingWrapperFilter does not cache

by Tobias Hill (JIRA)

CachingWrapperFilter does not cache ------------------------------------ Key: HSEARCH-136 URL: http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-136 Project: Hibernate Search Issue Type: Bug Affects Versions: 3.0.0.GA Reporter: Tobias Hill See http://forum.hibernate.org/viewtopic.php?p=2369054#2369054 The CachingWrapperFilter uses the reader instance as a key for the caching. In HibernateSearch readers seems to be wrapped into a MultiReader which by itself is new each time and thus defeat the cache purpose. -- 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

18 years, 2 months

2
1
0 / 0

[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

18 years, 2 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

18 years, 2 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

18 years, 2 months

2
5
0 / 0

[Hibernate-JIRA] Created: (HHH-2957) ActionQueue Insertion sort performance degrades exponentially

by Jay Erb (JIRA)

ActionQueue Insertion sort performance degrades exponentially ------------------------------------------------------------- Key: HHH-2957 URL: http://opensource.atlassian.com/projects/hibernate/browse/HHH-2957 Project: Hibernate3 Issue Type: Improvement Components: core Affects Versions: 3.2.5 Reporter: Jay Erb Attachments: ActionQueue.java, NewInsertActionSorter.java The algorithm for sorting entity insertions performs poorly for when flushing large numbers of entity insertions. There are a few reasons for this: 1. The sort used linear searches over lists which required nested looping. 2. ArrayLists were used to hold the insertion events. ArrayLists give good performance for looping but they have a couple of significant drawbacks: a. Whenever a new item is added to the list, the list is rebuilt with the new size, which causes another loop over all the entries in the list. b. Since it is an array, a contiguous block of memory must be found to hold the array. As the array get large, it gets harder and harder to find a contiguous block large enough. This causes the garbage collector to be run more often, which obviously reduces performance again. I changed the algorithm so that the product of the sort is exactly the same. The difference is that I used hashes for searches and LinkedLists for storing the insertions. The performance is linear. Attached are my changes. -- 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

18 years, 2 months

2
13
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

18 years, 2 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

18 years, 2 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

18 years, 2 months

2
6
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues December 2007