Closed (fixed)
Project:
Search API ranges
Version:
7.x-1.x-dev
Component:
Code
Priority:
Critical
Category:
Task
Assigned:
Unassigned
Reporter:
Anonymous (not verified)
Created:
18 Mar 2011 at 16:39 UTC
Updated:
8 Sep 2017 at 10:12 UTC
Jump to comment: Most recent
Comments
Comment #1
Anonymous (not verified) commentedComment #2
drunken monkeyI don't really understand a) the purpose of the method (i.e., why you can't just use the normal
execute()), and b) why you need it to be a method.Regarding a) I tried to look up the code to see what it does, but includes/query.inc only contains a few class properties copied from the normal query class, no methods. Maybe you accidentally removed the new part and kept the wrong one? Or am I just looking in the wrong place?
Regarding b): If you don't want to override an old method, but add a new one that only you would use — why make it a method at all? Since the class has no "real" protected properties (i.e., none without an accessor method), this should be perfectly possible to implement as a normal function in your module.
Also, the use case is far from clear for me. (If you don't really need the method, as stated above, it doesn't matter, though.)
Comment #3
Anonymous (not verified) commentedHi, sorry I accidentally left that query.inc empty. The point is to be able to do a custom search query without
drupal_alter()and withoutsearch_api_current_search(). To find the slider's min/max values, I need to get unaltered "pure" results and these results may not be stored in the Search API system.So I needed to run a
$query->executeClean()like this:I removed two lines from execute(():
1.
drupal_alter('search_api_query', $this);Because I need to do a "pure" unalterable query to find min/max values. Otherwise I would end up altering my own min/max query with my
search_api_ranges_search_api_query_alter(), but this cannot happen. The min/max queries need to be on a separate track, uninfluenced by anything else.2.
search_api_current_search(NULL, $this, $response);This makes Search API believe there are multiple searches on the same page, which leads to unwanted behavior. The min/max queries should be considered "stand-alone", not influencing Search API.
Comment #4
Anonymous (not verified) commentedYou can see what I'm doing in
search_api_ranges_minmax_execute(). It looks up the lowest and highest value for a given field, given the current search's keys and filters.Comment #5
drunken monkeyOK, I guess that makes sense. However, I'm sure there are other ways to prevent you from altering your own query, and removing the
drupal_alter()call might lead to false min/max results for facetted searches.Anyways: as said, just doing this in a function instead of a method on the search query is probably the easiest way to do this. If it's absolutely essential that it's a method, then just replace the
search_api_query()call withnew SearchApiRangesQuery($index, $options).Comment #6
Anonymous (not verified) commentedAha, of course I should just add the function to search_api_ranges.module. I didn't think of that :) Good point about the drupal_alter actually. I'll find another way, like adding a $option['skip_ranges_alter'] = 1 or something like that.
Comment #7
Anonymous (not verified) commentedThe custom function requires quite a re-write of the original execute() function. I'm trying this now:
But no luck:
Fatal error: Call to protected method SearchApiQuery::preExecute() from context ''What would the right approach be?
Comment #8
drunken monkeyAh, yes, the
preExecute()andpostExecute()methods are protected, didn't think of that. However, as long as you aren't dealing with an overridden query class, those methods will be empty anyways. It should therefore be relatively harmless, in most cases, to just omit these calls.Comment #9
Anonymous (not verified) commentedThanks, we'll try that as long as it works. Just committed this.