[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-200?pag... ] Hardy Ferentschik commented on HSEARCH-200: ------------------------------------------- I think per DirectoryProvider is fine. The question I ask myself is how this approach with two property sets - batch vs transaction. For the initial properties we exposed - max_merge_docs and merge_factor it made sense to have this separation, since we wanted to benefit from different values for indexing vs searching. max_field_length seems different. The differentiation between batch vs transaction does not matter here, right? Do we stick with it just for consistency? Would it maybe not be better to do something like this: hibernate.search.[default|<indexname>].max_field_length, hibernate.search.[default|<indexname>].[batch|transaction]?.merge_factor, hibernate.search.[default|<indexname>].[batch|transaction]?.max_merge_docs, hibernate.search.[default|<indexname>].[batch|transaction]?.max_buffered_docs Meaning you can specify hibernate.search.[default|<indexname>].merge_factor which will apply the same setting for batch and transaction. I am actually not sure whether batch vs transaction makes sense for ram_buffer_size as well? Alternatively, we could think about finding a way to expose the IndexWriters. This way you could get hold of them and set values we haven't exposed yet programmaticly. -- 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-200?pag... ] Sanne Grinovero commented on HSEARCH-200: ----------------------------------------- Hi Hardy, sorry I didn't refresh the page, I wrote my previous comment without seeing your post. Nice to see we were worried about the same point. I think we should permit the user to set it, as an "advanced option", but write some warning about the fact that data may be truncated (it already is truncated currently of course) -- 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-200?pag... ] Sanne Grinovero updated HSEARCH-200: ------------------------------------ Attachment: HSEARCH-200.patch Here is my very trivial proposal. I've added MAX_FIELD_LENGTH, TERM_INDEX_INTERVAL and MAX_BUFFERED_DELETE_TERMS 95% of work is in documentation: I added explanations for the new parameters and cleaned up other sections about indexing configuration, as we had much information repeated and scattered about the chapters. I didn't make any JUnit tests, as it would require some mocking library to test this and the change is really trivial; even so I verified all is ok just stepping through the debugger. Let me know what you think about it, or if I should remove some parameter to hide it's control. -- 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-200?pag... ] Sanne Grinovero closed HSEARCH-200. ----------------------------------- Resolution: Fixed Fix Version/s: 3.1.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