Re: Person appearing twice on homepage, group pages, search results, etc.

[Jason Stirnaman]

In SolrUpdater.rb#reindex_before_destroy at line 10 was failing because the private method #reindex_associated_works was being called by Membership (as self). I changed the method to "protected" instead of "private" and it works. Also, private methods shouldn't be called by accessors (self), but #reindex_before_destroy fails without the accessor even when it's protected.

On the other hand, #reindex_after_save seems to work as expected when #reindex_associated_works is called without an accessor and when #reindex_associated_works is a private method.

I'm baffled why one works and the other doesn't. And I'm still suspicious that no one else is complaining about this since Howard did that refactoring 8 months ago. 

Jason

On Thu, Jul 19, 2012 at 4:24 PM, Jason Stirnaman <stirn...@gmail.com> wrote:

We're still having the problem where people photos sometimes appear twice on homepage, group pages, or search results, i.e. anywhere Solr people_data field is used. I think Howard worked on this a while back so I'm curious to know if anyone else is experiencing it or if we've regressed due to my local customizations?

I think I've at least partially identified the cause:

All of Person A's works aren't getting reindexed when the person's group memberships change. So then if you add or change Coauthor A's works then the shared works get re/indexed with Person A's current memberships, but the rest of Person A's works aren't reindexed. So the freshly updated works in Solr have the current group ids of Person A, whereas the non-updated works contain the Person's old group ids in the people_data field. The Solr person facet returns the two different people_data records and as far as the view is concerned there are two different people.

 I still don't know if it always happens or just under certain conditions.

Jason

[Howard Ding]

Hi,

I suspect that we're not complaining simply because we put in a batch job that reindexes every night, so even if this went wrong it the problem was fixed each night.

Thanks for the fix - I'll look at it on Monday. Haven't had much time for Bibapp lately.

Howard

--
You received this message because you are subscribed to the Google Groups "bibapp-dev" group.
To post to this group, send email to bibap...@googlegroups.com.
To unsubscribe from this group, send email to bibapp-dev+...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/bibapp-dev?hl=en.

[Jason Stirnaman]

Turns out that I may have to rescind my "fix". I thought I had #reindex_before_destroy working - it did in one scenario - but now I'm unable to make it work again. Maybe I restarted webbrick without also restarting delayed_job. In any case, using :self doesn't appear to matter much.

Yes, we do regular reindexing as well and I thought that would be sufficient, but there are times when our staff doing the updates want the faculty to review their profile the same day.

Jason