[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-361?pag... ] Hardy Ferentschik commented on HSEARCH-361: ------------------------------------------- How do you cope with class bridges? -- 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-361?pag... ] Erel Magnus commented on HSEARCH-361: ------------------------------------- I think the solution should accomodate for more situations otherwise some people will flip over and it might turn up as very expensive thing to fix or to detect as it did for me . For example considering your solution if the developer adds a class bridge then immidiately all updates become very expensive and they have no idea why. There are three options that I can recommend: First of all , we should consider the possibility that fieldbridges/classbridges will produce stateful index terms. E.g. When indexing at 1PM it produce A and on 3PM B or some random value. In that context your solution would not work. The only thing that would work is like its done in HSEARCH-5 http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-5 which is to store a hash of the fields in the lucene document. So the first mode would be to index all the fields and to compare the hash. This solution cosumes some resources during indexing but at least the IndexReader remains "clean" and the index remains optimized. Reading the data should be quick thanks to caches. Secondly, if all fields are stored in the index then we can check that they are the same. So the second mode would be to simply compare the values. This solution is the most robust. Thirdly, assuming there are no stateful index terms (you dont know that) or there are no custom field bridges (you do know that) you can use what you suggested above . So the third mode would be to check for dirty fields. It should also be possible to enable granular behaviour so some fields would use hash/stored fields and some fields use dirty checks. I think the setting should be controlled in the @FieldBridge and @ClassBridge and then passed using the LuceneOptions to the FieldBridge implementation to provide full control to the developer. E.g. @FieldBridge( updateMode = UpdateMode.DIRTY , impl = ...) As for classbridge, there is no simple way for you to know what fields they add and there is no 1:1 relationship between the annotation and the implementation so I recommend if there are any class bridges we go for the hash automatically (and not for reindexing). The default for updateMode must accommodate for backwards compatibility. I suggest there should be a configuration entry variable for the default and it should be set to "auto" , or any of the other options mentioned above. If set to "auto": 1. If no custom fieldbridges/classbridges are used, go for the dirty check strategy. 2. If there are some custom field bridges, then go for the hash. Note this would cost a reindexing of the old index because the hash field needs to be added for the first time, but at least it works right and once the hash is there it works. 3. If all fields are stored, go for the comparison. So for me I would then install the new hibernate , and without doing any coding/configuration there should be much less index updates. So out of the box the solution has good value. After this I would just configure dirty checking explictly by changing all the @FieldBridge annotation since I don't have any stateful fields - and get a bit more CPU performance. I dont use class bridges so that would do it. Regards, Erel Magnus -- 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-361?pag... ] Emmanuel Bernard commented on HSEARCH-361: ------------------------------------------ Yes I think we would need some additional *Bridge methods to accomodate a better algo than the one I initially described. But we need to do the initial work first :) BTW the "new" methods should be put on a different API like IncrementalBridge or something like that. -- 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-361?pag... ] Emmanuel Bernard commented on HSEARCH-361: ------------------------------------------ My slight problem with that approach is that is puts a heavy burden for simple implementations as they have to implement the isDirty from scratch. I guess we could offer a default simple implementation of it for StringBridges and use the isDirty bare meta approach to others. BTW this should nto be limited to ClassBridge ,right? I don't see why. I am not fully following the "breaking APIs is better" argument though. -- 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-361?pag... ] Emmanuel Bernard updated HSEARCH-361: ------------------------------------- Fix Version/s: (was: 3.2.0.Beta3) 3.3.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-361?pag... ] Tom Waterhouse commented on HSEARCH-361: ---------------------------------------- This is a big issue for embedded collections. We have nested associations for which non-indexed field updates are causing a load of all related entities. In the case where indexed fields are updated the related index update cost makes sense. When updating a non-indexed field of an embedded object the expectation is that no extra index processing will occur. -- 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-361?pag... ] Sanne Grinovero reassigned HSEARCH-361: --------------------------------------- Assignee: Sanne Grinovero -- 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-361?pag... ] Sanne Grinovero commented on HSEARCH-361: ----------------------------------------- I'm currently working on this, I'll propose a patch soon but going to cover only the most simple case; If any ClassBridge or BoostStrategy is applied, indexing won't be skipped; also collection events won't be optimized yet, taking care only of onPostUpdate events. Assuming Emmanuel will like the approach, please help with patches to solve the cases I'm not covering if you need more. -- 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-361?pag... ] Sanne Grinovero commented on HSEARCH-361: ----------------------------------------- Hi j nadler, I pushed my proposal to github for reviews, please try it out: https://github.com/Sanne/hibernate-search/tree/HSEARCH-361 (please note the "HSEARCH-361" is the name of the branch to see). I believe this implementation should be able to handle your requirement, please let me know. I definitely will need feedback before pushing this to main repository, both from you and Emmanuel or Hardy. -- 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-361?pag... ] Sanne Grinovero commented on HSEARCH-361: ----------------------------------------- yes, it's on jboss.org Nexus as a SNAPSHOT https://repository.jboss.org/nexus/content/repositories/snapshots/org/hib... -- 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-361?pag... ] Tom Waterhouse commented on HSEARCH-361: ---------------------------------------- In my test I update a non-indexed String field. The boolean property value isn't changed, but the object instance its value is held in is different than the original instance. -- 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-361?pag... ] Tom Waterhouse commented on HSEARCH-361: ---------------------------------------- The latest changes resolve the issue in my tests. -- 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-361?pag... ] Tom Waterhouse commented on HSEARCH-361: ---------------------------------------- hibernate-search-parent-3.4.0-SNAPSHOT has not been posted yet to https://repository.jboss.org/nexus/content/repositories/snapshots/ -- 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-361?pag... ] Stephane Epardaud commented on HSEARCH-361: ------------------------------------------- Note that HSEARCH-5's fix with hashing makes this work with bridges. -- 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-361?pag... ] Emmanuel Bernard commented on HSEARCH-361: ------------------------------------------ Added a pull request for the better dirty computation https://github.com/hibernate/hibernate-search/pull/31 -- 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-361?pag... ] Sanne Grinovero resolved HSEARCH-361. ------------------------------------- Resolution: Fixed -- 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