[ http://opensource.atlassian.com/projects/hibernate/browse/HSEARCH-679?pag... ] j nadler commented on HSEARCH-679: ---------------------------------- I believe we've been having this same problem for a while. In the worst cases it can cause tens of thousands of records to load, which takes over 5 minutes. -- 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-679?pag... ] Sanne Grinovero commented on HSEARCH-679: ----------------------------------------- Hi Tom, thanks that's a great finding. Would you like to propose a patch? I'll assign this to me in the meantime to make sure we don't forget about it in 3.4 -- 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-679?pag... ] Sanne Grinovero updated HSEARCH-679: ------------------------------------ Affects Version/s: (was: 3.4.0) 3.3.0.Final Fix Version/s: 3.4.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-679?pag... ] Tom Waterhouse commented on HSEARCH-679: ---------------------------------------- I cannot figure out a way to determine the collection that triggered the update event. The AbstractCollectionEvent instance passed to FullTextIndexEventListener.onPostUpdate() has the owning entity information, but the collection associated with it is empty. The ActionQueue associated with the EventSource does have the updated collection, but ActionQueue does not have a getter for any of the fields that contain the objects that have associated actions. Any help would be appreciated. -- 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-679?pag... ] Hardy Ferentschik updated HSEARCH-679: -------------------------------------- Component/s: engine -- 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-679?pag... ] Tom Waterhouse commented on HSEARCH-679: ---------------------------------------- Your changes fix the issue, using the attached unit test. Note that the test doesn't assert any conditions, just allows the Hibernate-generated SQL to be viewed. -- 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-679?pag... ] Sanne Grinovero commented on HSEARCH-679: ----------------------------------------- Hi Tom, did you come up with a possible test? I think we need to release 3.4 soon, tagging a CR today. No worries we can make a 3.4.1 if this doesn't make it, so you won't need to wait for 3.5. To answer your mailing-list question on testing: Creating test data you'll have initialized entities, but after the test fixture has been setup you should close the Session, and use a new Session in the test method. this will load data and collections which are not initialized (make sure they are not eagerly loaded). This is how we usually make tests and what I would try in this case, but if this doesn't work out or you feel more comfortable with mocks I think that would be fine as well. Just we'll need to discuss on mailing list about which mock library to depend on (I like easymock, but can't make this decision alone). -- 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-679?pag... ] Tom Waterhouse commented on HSEARCH-679: ---------------------------------------- I've attached a candidate test for HSEARCH-679. I used Mockito for mocking, as I ended up having to mock SearchFactoryImplementor and Worker. -- 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-679?pag... ] Tom Waterhouse updated HSEARCH-679: ----------------------------------- Attachment: HSEARCH-679-test-updated.zip Updated test files * no company copyright * tests moved to org.hibernate.search.test.event -- 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-679?pag... ] Sanne Grinovero commented on HSEARCH-679: ----------------------------------------- Hi Tom, thank you very much, I've been updating your test even more to cover the "corner cases" I referred to previously; it's quite tricky but I think you're right this optimization is very important. All my changes are on github, on branch "HSEARCH-679": https://github.com/Sanne/hibernate-search/tree/HSEARCH-679 It's looking good to me and I've sent a pull request to trigger review from other committers, your feedback is appreciated as well. -- 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-679?pag... ] Emmanuel Bernard resolved HSEARCH-679. -------------------------------------- Resolution: Fixed Applied, thanks :) -- 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-679?pag... ] Adam Harris edited comment on HSEARCH-679 at 5/19/11 10:02 AM: --------------------------------------------------------------- I'm running Hibernate Search 3.4.0.Final with Hibernate Core 3.6.3.Final, and this doesn't appear to be fixed. Perhaps I have another corner-case that isn't accounted for in this patch. Here is my model: {code:java} public class A { @Field private String name; @ContainedIn private Collection<B> b; private A parent; // Not indexed private Collection<A> children; // Not indexed } {code} {code:java} public class B { @IndexEmbedded private A a; } {code} USE CASE #1 If I add a new instance of B to A's collection, the only change to A is the row version is incremented. This not only leads to Hibernate Search updating the index for A, but then it cascades to all of the B's in the collection even though there is nothing to change. USE CASE #2 In addition, if I add a new instance of A to A's "children" collection (which this hierarchy isn't even represented in the index), it performs all the same index updates as USE CASE #1. For simplicity, I've eliminated some other classes that are referenced in class B, but this problem results in an explosion of objects being unnecessarily loaded from the DB and indexes updated with zero new information. was (Author: aharris): I'm running Hibernate Search 3.4.0.Final with Hibernate Core 3.6.3.Final, and this doesn't appear to be fixed. Perhaps I have another corner-case that isn't accounted for in this patch. Here is my model: public class A { @Field private String name; @ContainedIn private Collection<B> b; private A parent; // Not indexed private Collection<A> children; // Not indexed } public class B { @IndexEmbedded private A a; } USE CASE #1 If I add a new instance of B to A's collection, the only change to A is the row version is incremented. This not only leads to Hibernate Search updating the index for A, but then it cascades to all of the B's in the collection even though there is nothing to change. USE CASE #2 In addition, if I add a new instance of A to A's "children" collection (which this hierarchy isn't even represented in the index), it performs all the same index updates as USE CASE #1. For simplicity, I've eliminated some other classes that are referenced in class B, but this problem results in an explosion of objects being unnecessarily loaded from the DB and indexes updated with zero new information. -- 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-679?pag... ] Adam Harris edited comment on HSEARCH-679 at 5/19/11 10:51 AM: --------------------------------------------------------------- I'm running Hibernate Search 3.4.0.Final with Hibernate Core 3.6.3.Final, and this doesn't appear to be fixed. Perhaps I have another corner-case that isn't accounted for in this patch. Here is my model: {code:java} @Indexed public class A { @Field private String name; @ContainedIn private Collection<B> b; private A parent; // Not indexed private Collection<A> children; // Not indexed } {code} {code:java} @Indexed public class B { @IndexEmbedded private A a; } {code} USE CASE #1 If I add a new instance of B to A's collection, the only change to A is the row version is incremented. This not only leads to Hibernate Search updating the index for A, but then it cascades to all of the B's in the collection even though there is nothing to change. USE CASE #2 In addition, if I add a new instance of A to A's "children" collection (which this hierarchy isn't even represented in the index), it performs all the same index updates as USE CASE #1. For simplicity, I've eliminated some other classes that are referenced in class B, but this problem results in an explosion of objects being unnecessarily loaded from the DB and indexes updated with zero new information. was (Author: aharris): I'm running Hibernate Search 3.4.0.Final with Hibernate Core 3.6.3.Final, and this doesn't appear to be fixed. Perhaps I have another corner-case that isn't accounted for in this patch. Here is my model: {code:java} public class A { @Field private String name; @ContainedIn private Collection<B> b; private A parent; // Not indexed private Collection<A> children; // Not indexed } {code} {code:java} public class B { @IndexEmbedded private A a; } {code} USE CASE #1 If I add a new instance of B to A's collection, the only change to A is the row version is incremented. This not only leads to Hibernate Search updating the index for A, but then it cascades to all of the B's in the collection even though there is nothing to change. USE CASE #2 In addition, if I add a new instance of A to A's "children" collection (which this hierarchy isn't even represented in the index), it performs all the same index updates as USE CASE #1. For simplicity, I've eliminated some other classes that are referenced in class B, but this problem results in an explosion of objects being unnecessarily loaded from the DB and indexes updated with zero new information. -- 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-679?pag... ] Sanne Grinovero commented on HSEARCH-679: ----------------------------------------- {quote}I don't understand your comment about UC#1. I know that index "updates" are really deletes and re-adds, but why does each B instance need to be re-indexed at all? Based on HSEARCH-361, since no indexed fields in A were changed, there's nothing to do in B's index. I don't index the row-version field (not even shown in my code snippets). If I were updating the A.name field, then I would understand why all of the B instances need to be rebuilt, but that's not my scenario.{quote} sorry I misread your example as a many-to-many; I think you're right there should be no need to update the index; the problem must hide in how we flag the association to B as "index triggering", being annotated with _@ContainedIn_, and dirty as well as you're updating it. Thanks, yes we should be able to do better! Looking forward for 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-679?pag... ] Sanne Grinovero commented on HSEARCH-679: ----------------------------------------- Please make sure you create a new issue to track this, or I will forget! Also, Adam was working on a test but maybe Adrian you have one too? Without a test it's hard for me to figure out the exact scenario; if somebody sends one we will attempt to fix it (or if you want to try fixing it yourself and figure as a project contributor that's great too, I can give some directions). For inspiration on how to make a test, the one committed as part of this issue by Tom and myself should be a good starting point (see the sources tab for a list of changes related to 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