With Solr 4.x, we've been given the ability to perform join queries.
In Drupal one of the main ways of creating references between nodes is using the entityreference module.
Unfortunately due to how we're storing the entityreference fields in the index with the apachesolr module, joins are not possible.
It would be wise to change the format of how entityreferences are stored in the solr index to be the solr IDs of the documents they reference.
Currently node IDs in solr look like this "8yx3v3/node/94388" but entityreference values in documents look like this "node:94388". I doubt many people are using the entityreferences in solr
I'm going to need to perform join's on the project I'm working on (or de-normalize my data more) but it seems that it would be a good idea to create proper IDs with entityreferences so that this functionality could exist.
Here's the solr join syntax.
http://wiki.apache.org/solr/Join
I'm starting to think since Solr 4 provides many other features not provided by solr 3.x and since there's also a new solarium for Solr 4.x, that perhaps it's time to fork this project to apachesolr 2.x and get the solr 4 functionality integrated. Since Solarium 3.x is based on Symphony framework name spacing, it would help with the move to D8 as well.
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | 1992974-8.patch | 1.36 KB | rpayanm |
| #7 | 1992974-7.patch | 0 bytes | rpayanm |
| #4 | 1992974-apachesolr4-entityref-join-4.patch | 1.38 KB | j0rd |
| #1 | 1992974-apachesolr4-entityref-join-1.patch | 1.38 KB | j0rd |
Comments
Comment #1
j0rd commentedHere's a sample patch, although it could break other peoples modules who depend on the existing format and additionally it will require that your index get rebuilt.
Comment #2
j0rd commentedChanging to needs review for testbot.
Comment #4
j0rd commentedTypo in previous patch. Oops.
Comment #6
amonteroComment #7
rpayanmComment #8
rpayanmups... 0 byte patch :P
Comment #10
atolborg commentedI think this is of great interest to me! Im working on a projekt where we have a distinction between 'primary content' and 'secondary content'. Primary content have urls, while secondary content are referenced from the primary content. Unfortunately we did not give much though to search indexing of the secondary content types. Please update this thread with news on how to index - in our case - the secondary content as part of the primary content.
Cheers!