I've recently upgraded our version of the apachesolr module (and the schema) and we are having a couple of issues with "duplicate" nodes being added to the index. This seems to be being caused by us inconsistently running cron on http and https, and hence the URL unique keys differing for the 2 items in the index. I'm sure we can solve this by ensuring cron is run over http only - but it did get me wondering why the unique key was changed in the latest version of the module, I think it used to be nid - which seemed to make sense.

I'm thinking of just changing my schema back to using the nid as the unique key and rebuilding the index - but before doing this I thought it would be a good idea to try and find out why the url was now being used, and hence what size hole I was digging for myself :)

Comments

robertdouglass’s picture

robertdouglass commented

The URL as unique index is to facilitate multisite search and non-node based content. The http(s) issue is interesting. Maybe we should strip the protocol bit off off of URIs?

mdixoncm’s picture

mdixoncm commented

Thanks for that Robert - I've been thinking a bit about using the URL as the key though and I might be being silly but I'm not sure it makes sense. I'm definitely no SOLR expert so the following might not be true :)

Potential issues I can see

1. If you change the path on a node then you will end up with 2 instances of the node in the index, as the key will be different when the index is updated?

2. On a multisite - if your sharing the node table and edit the node on one of your multisites then the node would be incorrectly indexed for your other sites - perhaps a better approach for the multisite would be to use the nid as the key, but to add the baseurl to the index (I think it may already be there) and to all the search queries. Maybe do something similar with multi-lingual sites too? Although I can see an issue with the teaser being stored being shared between the multi sites having the wrong path in the link to the node.

random musings - apologies if the above have been hammered out / solved already :)

pwolanin’s picture

pwolanin commented

This is solved in the 6.x version by using a non-url hash for the unique key - at some point, perhaps, the changes will be backported.

JacobSingh’s picture

JacobSingh commented
Status: Active » Closed (won't fix)

This has been sitting around for 7mo