Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
See topic title, urgently needed.
Comment | File | Size | Author |
---|---|---|---|
#22 | 1897556-22.patch | 1.07 KB | pwolanin |
#9 | 1897556-9.patch | 83.66 KB | Nick_vh |
#7 | 1897556-7.patch | 77.04 KB | Nick_vh |
#5 | 1897556-5.patch | 65.64 KB | Nick_vh |
#3 | 1897556-3.patch | 51.67 KB | Nick_vh |
Comments
Comment #1
Nick_vhFirst take, will work more on this when I have time.
Comment #2
Nick_vhComment #3
Nick_vhChecking if this breaks anything, also adding some more typing in the function definitions.
Comment #5
Nick_vhComment #7
Nick_vhComment #9
Nick_vhMeh, stupid menu system
Comment #10
Nick_vhComment #11
Nick_vhCommitted this, will do a follow up later on.
Updated :
* apachesolr.drush.inc
* all the facetapi plugins
* Apache_Solr_Document.php
* Drupal_Apache_Solr_Service.php
* Solr_Base_Query.php
* apachesolr.admin.inc
* apachesolr.api.php
* apachesolr.index.inc
We should do all the other ones still.
Comment #12
ianthomas_ukIs this change intentional? It's not a documentation change, and has broken a couple of my facets (single value taxonomy fields).
Comment #13
ianthomas_ukI've proposed a fix for the facets this broke at http://drupal.org/node/1979506
Comment #14
Nick_vhClosing this issue as it does not really has a good defined action item. Thanks for finding a little issue here.
Comment #15
pwolanin CreditAttribution: pwolanin commentedneeds to eb backported?
Comment #16
pwolanin CreditAttribution: pwolanin commentedsetting back to needs work. I think @ianmthomasuk is correct in #12 that the change to the field mappings was a mistake.
Comment #17
ianthomas_ukEven if it was committed accidentally, I think the behaviour in 1.2 makes sense and has the benefit that you can sort by the single-value field. The only exception I know about is taxonomy fields, which is addressed in https://drupal.org/node/1979506
Comment #18
pwolanin CreditAttribution: pwolanin commented@ianmthomasuk - I thought we were already adding a single value version (the 1st value) for every field when indexing?
Comment #19
ianthomas_uk@pwolanin That's not what happens on my site, using 1.1 plus a few patches that shouldn't change that behaviour.
Comment #20
pwolanin CreditAttribution: pwolanin commented@ianmthomasuk - check your index. It's possible we are not exposing that as a sort in the UI, but it should be there.
Comment #21
pwolanin CreditAttribution: pwolanin commentedSee apachesolr.index.inc:
Comment #22
pwolanin CreditAttribution: pwolanin commentedHere a patch reverting that change, plus a minor cleanup.
Comment #23
pwolanin CreditAttribution: pwolanin commentedComment #24
ianthomas_ukI've been having a discussion with @pwolanin on IRC about the merits of this patch and whether it's desirable to attempt to index a multi-value Drupal field as a single value Solr field.
Benefits:
* You can change the cardinality of the field without re-indexing
* You can sort on the field
Drawbacks:
* The sort order can be inconsistent, as it depends on the order of the values in the multi-value field (e.g. if you have two nodes with multi-value price fields of (29.99, 19.99) and (24.99, 34.99) and you sorted by price asc then the second node would be listed first, when you probably wanted to sort by minimum price or maximum price).
* Slightly increases index size / indexing time
I'm marking this RTBC as an all-singing all-dancing solution would take quite a lot of work, and this at least resolves the regression for people upgrading from <1.1. It does need a release note to warn users of 1.2 that some of their fields will change back to their old names.
Comment #25
pwolanin CreditAttribution: pwolanin commentedcommitted