Closed (fixed)
Project:
Apache Solr Search
Version:
7.x-1.x-dev
Component:
Code
Priority:
Normal
Category:
Task
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
18 May 2011 at 15:27 UTC
Updated:
4 Jan 2014 at 00:53 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
cpliakas commentedChanging title to be more descriptive, postponing until Facet API makes the change.
Comment #2
nick_vhThis patch should not be committed until facetapi committed their changes from #1161434: Modify "query type" key in facet definition to accept an array
Comment #3
nick_vhIgnore last patch, this one includes the queryType
Comment #4
nick_vhMistake
Comment #5
nick_vhNew patch following the changes of #1161434: Modify "query type" key in facet definition to accept an array
Also did some white spacing/formatting formatting
Comment #6
nick_vhNew one that applies to latest dev
Comment #7
nick_vhAdded an extra query so we can get the stats form the field without, this should be cached so we only do this once per field per time period
Need help in this!
Comment #8
nick_vhSeems like this breaks OR facets. Still have to confirm if it is this patch that breaks it or the facetapi patch
Comment #9
cpliakas commentedChanging status from "postponed" to "needs review" since the API change at #1161434: Modify "query type" key in facet definition to accept an array has been committed to Facet API.
Comment #10
nick_vhI just need someone to confirm that this patch does not break the OR facets in a site. If that is done, we can commit this also
Comment #11
cpliakas commentedI applied the patch, and the OR facets are working perfectly for me.
Comment #12
cpliakas commentedOne word of caution, if you commit this patch then Apache Solr Search Integration cannot roll a new release before Facet API does. We will either have to coordinate releases, or you could also leave the old "query type" key in there as Facet API still respects it. This would definitely look silly in the code since it would have both "quert type" and "query types", however it would mitigate upgrade issues.
Just a thought,
Chris
Comment #13
nick_vhSo you say I should add something like below? I'm not in favor of that since it still could break the facet_slider module then and get undesirable results. Is there a way to tell drupal that a minimum version of a module as dependency is required?
I don't see the problem in waiting for an equal release of facetapi, or telling people that they should use the latest dev from facetapi in combination with the latest dev of apachesolr. Suggestions are wanted here :-)
Comment #14
cpliakas commentedHey Nick.
Your's code is what I was thinking. We are trying to resolve the issue of people upgrading Apache Solr and NOT Facet API. If people are using Facet API <= beta7 then the sliders won't work anyways, so I am not sure this is a big deal. I also wouldn't want to urge people to use the dev release of a module.
Regarding requiring a specific version of a module, this is done in the .info file via the dependencies key. Since the Facet API integration piece isn't a separate module, there is no clean way to do this.
For me, once Facet API goes RC, I plan on removing support for legacy backwards compatible code. Maybe we can add a @todo to remove the "query type" key once Apache Solr goes RC and say "You need at least Facet API >= Beta8"?
~Chris
Comment #15
nick_vhWill test if this is working and if it is I will commit it to the development version
Comment #16
nick_vhSeems like all is working!
Comment #17
nick_vhUps, forgot to do the git add -N
Comment #18
nick_vhThis todo comment was added in this patch
Comment #19
cpliakas commentedLooks good to me.
Comment #20
nick_vhAnd committed! Great!