I'm working on a project which includes the following activated modules:
Drupal core 8.2.3
Database Search 8.x-1.0-beta4
Search API 8.x-1.0-beta4
Search API Term Handlers 8.x-1.0-beta4
Views 8.2.3
I have a list of nids which need to be excluded from the search result of the site-wide search. The search uses Search API and has been setup using Views.
The table in the database is: "search_api_db_default_index"
The field I wish to target is: "nid"
I wasn't able to get HOOK__search_api_query_alter or HOOK_search_api_results_alter to fire, so I am attempting to manipulate the query through HOOK_views_query_alter.
I have attempted to use both the "addWhere" and "addCondition" methods with the following syntax:
When using the addCondition method, I attempted
$query->addCondition('search_api_db_default_index.nid', $oneBadNid, '<>');
and
$query->addCondition('search_api_db_default_index.nid', $manyBadNids, 'NOT IN');
and when using the addWhere method, I attempted
$query->addWhere('AND', 'search_api_index_default_index.nid', $oneBadNid, '<>');
and
$query->addWhere('AND', 'search_api_index_default_index.nid', $manyBadNids, 'NOT IN');
Regardless of whether or not I prefix the field with the table name, searching always results in triggering the following notice:
Unknown field in filter clause: 'search_api_db_default_index.nid' .
It seems that the field name is always wrapped in an html encoded string representing a single quotation, but this occurs both when using double quotations or single quotations around the supplied table.field parameter.
I am not even sure that this is what is keeping me from altering my query, but it is the only thing close to an error which I have discovered in this process. It's also possible that I'm simply not supposed to be targeting the table in the manner written, but I did not find any documentation directing me to the proper methodology.
I would appreciate any insight into this issue! Thanks!
Generally you can use
$fields = $query->getIndex()->getFields();
on the query to get an array of fields you can use within the search_api query.
Piggy-backing off of Nebel54's comment, and attempting this on my own, you don't need to include the 'table' name when setting the addCondition. However, I did need to use hook_search_api_query_alter over a views-specific one.
function mymodule_search_api_query_alter(\Drupal\search_api\Query\QueryInterface &$query) {
// Ensure field_myfield is being indexed
$fields = $query->getIndex()->getFields();
if (isset($fields['field_myfield'])) {
$query->addCondition('field_myfield', 'myvalue', '<>');
}
}
Related
I have a website that was produced in sitecore that i have inherited. The search does not seem to be working correctly. Basically documents do not seem to be returned correctly. I have noted that there is the default sitecore_web_index index and also a custom index that seems to index the same content more or less. Currently the search queries the custom index however I would like to change the query to the default index to see if the document is then returned. I was told you can specify which index to use but the person never told me how to do it. Does anyone know how i can change this?
Sitecore 8 content search uses Sitecore.ContentSearch.ContentSearchManager.GetIndex(...) method to retrieve chosen index.
You can pass either:
Index name as a string:
Sitecore.ContentSearch.ContentSearchManager.GetIndex("sitecore_web_index")
IIndexable item - in this case Sitecore will try to find first registered index for you:
Sitecore.ContentSearch.ContentSearchManager.GetIndex(iIndexable)
Just find where GetIndex is used in your code and replace it with a default index name.
One thing you should be aware of - there is a chance that your custom index has some customization added (like computed fields, list of fields indexed etc). Be careful with any changes. Maybe there are other reasons why your search doesn't work. Try using IndexingManager app to rebuild the indexes and see if it helps.
You also need to remember that on Content Manager environment, the "sitecore_master_index" will be used, and on CD Environment the "sitecore_web_index" will be used
so this can lead to test errors
You can try to get the index dynamically, in that case, the code will select the correct index use, According to their environment
var indexable = Sitecore.Context.Item as SitecoreIndexableItem;
ISearchIndex index = ContentSearchManager.GetIndex(indexable);
using (IProviderSearchContext context = index.CreateSearchContext())
{
//search code...
}
Had to do it this way ...
var indexable = (SitecoreIndexableItem)Sitecore.Context.Item;
I am writing a simple app in django that searches for records in database.
Users inputs a name in the search field and that query is used to filter records using a particular field like -
Result = Users.objects.filter(name__icontains=query_from_searchbox)
E.g. -
Database consists of names- Shiv, Shivam, Shivendra, Kashiva, Varun... etc.
A search query 'shiv' returns records in following order-
Kahiva, Shivam, Shiv and Shivendra
Ordered by primary key.
My question is how can i achieve the order -
Shiv, Shivam, Shivendra and Kashiva.
I mean the most relevant first then lesser relevant result.
It's not possible to do that with standard Django as that type of thing is outside the scope & specific to a search app.
When you're interacting with the ORM consider what you're actually doing with the database - it's all just SQL queries.
If you wanted to rearrange the results you'd have to manipulate the queryset, check exact matches, then use regular expressions to check for partial matches.
Search isn't really the kind of thing that is best suited to the ORM however, so you may which to consider looking at specific search applications. They will usually maintain an index, which avoids database hits and may also offer a percentage match ordering like you're looking for.
A good place to start may be with Haystack
I've put together a simple search form, with a search box and a couple of filters as dropdowns. Everything works as you'd expect, except that I want the behavior to be that when the user leaves everything completely blank (no search query, no filters) they simply get everything returned (paginated of course).
I'm currently achieving this by detecting this special case and querying my local database, but there are some advantages to doing it 100% with CloudSearch. Is there a way to build a request that simply returns a paginated list of every document? In other words, is there a CloudSearch equivalent to "SELECT id FROM x LIMIT n?"
Thanks in advance!
Joe
See the Search API.
?q=matchall&q.parser=structured will match all the documents.
These easiest way would be to use a not operator, so for example:
?q=dog|-dog
would return all documents that contained 'dog' and also did not contain 'dog'. You would need to intercept the special case, as you are already, and just substitute a query/not query combo and you should get everything back.
For someone looking for an answer using boto3.
CLOUD_SEARCH_CLIENT = boto3.client(
'cloudsearchdomain',
aws_access_key_id='',
aws_secret_access_key='',
region_name='',
endpoint_url="https://search-your-endpoint-url.amazonaws.com"
)
response = CLOUD_SEARCH_CLIENT.search(
query="matchall",
queryParser='structured'
)
print(response)
I would like to do something like:
App.Model.find({unique_attribute_a: 'foo'}).objectAt(0).get('attribute_b')`
basically first finding a model by its unique attribute that is NOT its ID, then getting another attribute of that model. (objectAt(0) is used because find by attribute returns a RecordArray.)
The problem is App.Model.find({unique_attribute_a: 'foo'}).objectAt(0) is always undefined. I don't know why.
Please see the problem in the jsbin.
It looks like you want to use a filter rather than a find (or in this case a findQuery). Example here: http://jsbin.com/iwiruw/438
App.Model.find({ unique_attribute_a: 'foo' }) converts the query to an ajax query string:
/model?unique_attribute_a=foo
Ember data expects your server to return a filtered response. Ember Data then loads this response into an ImmutableArray and makes no assumption about what you were trying to find, it just knows the server returned something that matched your query and groups that result into a non-changable array (you can still modify the record, just not the array).
App.Model.filtler on the other hand just filters the local store based on your filter function. It does have one "magical" side affect where it will do App.Model.find behind the scenes if there are no models in the store although I am not sure if this is intended.
Typically I avoid filters as it can have some performance issues with large data sets and ember data. A filter must materialize every record which can be slow if you have thousands of records
Someone on irc gave me this answer. Then I modified it to make it work completely. Basically I should have used filtered.
App.Office.filter( function(e){return e.get('unique_attribute_a') == 'foo'}).objectAt(0)
Then I can get the attribute like:
App.Office.filter( function(e){return e.get('unique_attribute_a') == 'foo'}).objectAt(0).get('attribute_b')
See the code in jsbin.
Does anyone know WHY filter works but find doesn't? They both return RecordArrays.
Trying to create an advanced segment (include) using regex (or any other filter mechnanism, contains with just the substring isn't working either) which uses the value of the custom variable value.
It ought to be straightforward, but it's driving me insane. I currently have this regex:
.*CLAS_LIBRARIES.*
which rightly matches a custom variable value of:
HOME/CLASMAIN/CLAS_LIBRARIES/
but when I apply the segment and then browse the custom variable values in the report, it contains values like:
HOME/
/museumcollections/
HOME/MAPS/
Tried wrapping it like this:
.*(CLAS_LIBRARIES).*
(.*)(CLAS_LIBRARIES)(.*)
to no avail.
What the hell is going on, and am I an idiot?
What's the scope of your custom variable? Can multiple sessions have different values?
Advanced segments will return any data that matches your query (e.g. in case of creating a segment for a specific page, GA will return data for all user activity which included that specific page as part of their navigation).