[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-226?pag... ] Emmanuel Bernard updated HSEARCH-226: ------------------------------------- Fix Version/s: 3.1.0.Beta2 -- 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-226?pag... ] Sanne Grinovero commented on HSEARCH-226: ----------------------------------------- that's very good news, I didn't dare to ask for it. -- 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-226?pag... ] Sanne Grinovero commented on HSEARCH-226: ----------------------------------------- what I had in mind is a little more complex, you committed for 225 but actually fixed this one. Sorry I should have put a better description ;-) The idea behind 225 was that if an entity is the only one in the DP, you could obtain efficient delete even using a IndexReader by avoiding the query completely, just "delete by term" (only the ID). That means that in this case you can use a different DeleteWorkDelegate (was thinking about an extension) of the base one which has getIndexInteractionType() --> PREFER_INDEXREADER (instead of NEED_INDEXWRITER as in current trunk) (or PREFER_INDEXWRITER, didn't benchmark it on writer yet). The extension of DeleteWorkDelegate would support deletion by both writer or reader, and can even override the current implementations to avoid bothering about the classname. That means that the task will be done in the most efficient way in any case. Also you may have noticed that the instantiation of the WorkDelegates is per directoryprovider, and are created at SessionFactory startup: so any logic about choosing the optimal delegate is evaluated only once, giving best throughput during indexing. You're welcome to assign it to me, as I have all the clode in my mind already... only I can't open a code editor before the weekend. -- 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-226?pag... ] Hardy Ferentschik resolved HSEARCH-226. --------------------------------------- Resolution: Fixed Seems I really solved this one with my commit to HSEARCH-225. Reopened HSEARCH-225 and assigned it to Sanne how has some plans for this issue. -- 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