[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-246?pag... ] Sanne Grinovero commented on HSEARCH-246: ----------------------------------------- What is the problem exactly? I suspect this is fixed already, but I'm not sure about what I should test. -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-246?pag... ] Sanne Grinovero commented on HSEARCH-246: ----------------------------------------- I just realised this is going to break the indexing examples in the book. To refresh your memory: your examples recommended to use purgeAll optimize on scrollable { index entity } optimize and I had added a flushToIndexes in this way: purgeall flushToIndexes optimize on scrollable { index entity } optimize to be sure to optimize AFTER the purge (and immediately after). If you "cancel" the first optimization by fixing this as described this tip to optimize is not good anymore (it would work, but the tip is about using less disk space). this issue is requiring to "shuffle" the order of operations as requested by the code, I don't think this is a good idea.. why would a developer issue more than one optimization anyway? I think the issue should be changed, so to not apply automatic optimizations during batch operations (disable the mod counter): we should not remove an explicitly requested "manual operation", or mess with the position of it in the queue. -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-246?pag... ] Sanne Grinovero commented on HSEARCH-246: ----------------------------------------- he well... we agree now but it's getting worse. I think we need to break our current backend API: public Runnable getProcessor(List<LuceneWork> queue); the backend only gets the list, we need some way to tell the backend this is not a commit but a "flushToIndexes". This is something that could be usefull anyway. What about something like "public Runnable getProcessor(WorkQueue queue);" making a transport object? so next time we need something we can just add methods or fields to it. I think this would break serializable compatibility, especially for JMS backend. Maybe we should support a new method in addition to the original: "public Runnable getProcessor(WorkQueue queue, boolean commit);" this could be useful to really share the indexwriter, enabling the <batch mode> as I meant it on the dev list: the IndexWriter is not released, but waits for next load of work, until a commit==true which will eventually trigger automatic optimization, really flush the IndexWriter and release it. Of course the old method would map to the new one defaulting to commit=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

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-246?pag... ] Hardy Ferentschik updated HSEARCH-246: -------------------------------------- Fix Version/s: (was: 3.1.0) 3.2.0 Move to post 3.1 since this changes the API -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-246?pag... ] Emmanuel Bernard updated HSEARCH-246: ------------------------------------- Fix Version/s: (was: 3.1.1) 3.2.0 -- 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

[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-246?pag... ] Sanne Grinovero closed HSEARCH-246. ----------------------------------- Resolution: Rejected Not needed anymore, using the MassIndexer it won't trigger index optimizations until the end. -- 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