I want to sort a result set by the minimum of several fields.
So after reading the functionquery documentation this is what I came up with:
sort={!func}min(dvd_available_from_tdt,dto_available_from_tdt)%20desc
I also tried:
sort=_val_:min(dvd_available_from_tdt,dto_available_from_tdt)%20desc
sort=_val_:"min(dvd_available_from_tdt,dto_available_from_tdt)"%20desc
sort=_val_:"min(dvd_available_from_tdt,dto_available_from_tdt)%20desc"
sort="{!func}min(dvd_available_from_tdt,dto_available_from_tdt)"%20desc
sort={!func}min(dvd_available_from_tdt,dto_available_from_tdt)%20desc
sort="min(dvd_available_from_tdt,dto_available_from_tdt)"%20desc
and also some other placements of the quotes. But no matter what I always get this error:
HTTP ERROR: 400
Missing sort order.
Can anyobody point me in the right direction?
Try using a query that matches all documents, with a constant score, plus a function.
http://localhost:8983/solr/select/?q=%3A+_val_:price&version=2.2&start=0&rows=10&indent=on&debugQuery=true
Also, upgrading to Solr 3.3 is not that painful, and there's all sorts of cool new toys like sorting by function.
It seems to be available only in solr 3.1. I am running 1.4.1
http://wiki.apache.org/solr/FunctionQuery#Sort_By_Function
Related
I am newest in Lucene.
I'm using Lucene.NET version 2.9.4.
What is the difference between these queries?
the first is:
title:hello AND tags:word
the second is:
+title:hello +tags:word
I testing a software, and I note that the first returns 3 records, and the second returns many records.
I observe that the first returns records where title and tags fields are fuel, but the second returns records where title and tags can be empty.
Is it the difference?
There is no difference between the two. clause1 AND clause2 is effectively shorthand for +clause1 +clause2
Similarly: clause1 clause2 = clause1 OR clause2
Note, there is really no equivalent for +clause1 clause2 using the boolean operators.
Are you sending the query over the Internet, if you are and not urlencoding the request correctly it could be misinterting the '+' as an encoded space and therefore lucene just runs the second query as if the +'s not there which would just OR the two parts and give the results you get.
title:hello tags:word
I was trying to set index type from exact to fulltext in neo4j shell, so i can do incasesensitive search with lucene query. So i used this command:
index --set-config Destination type fulltext
but it didn't work. Still couldn't do case insensitive search, so a played around and change some other values, like _blueprints:type and to_lower_case.
That didn't do any good.
Now it somehow ignores first character of name value ( weird ! ) . So if i am searching for "London" for example and i type "Lon" it returns nothing. But if i type "ond" it returns the node. The same for every node.
I tried setting everything back to normal. Didn`t help.
What did i mess up? What am i missing?
I am using a Everyman PHP library to communicate with database.
I created new index with "to_lower_case" property.
I think that will solve my problem, just have to convert string to lower case before inserting it into query. It seems to work.
Setting configuration afterwards doesn't update already indexed values (as the shell notes, I think). If you've created your index with "to_lower_case=true" then additions as well as queries will have the values converted to lower case. Calling Index#get will still require you to lower-case it yourself.
I am trying to store very simple comments in a wide row, but the problem is that i want to have top comments.
So at first I have tried to use UTF8 comparator type and each column name would begin by likes amount and would be followed by timestamp, for example:
Comments_CF = {
parent:{
8_timestamp: comment,
5_timestamp: comment,
1_timestamp: comment,
...
}
...
}
The problem with this approach is that for example 2_timestamp > 19_timestamp because lexicographically 2 is bigger than 19
I could probably store top comments in a separate CF but then i would need to do two queries instead of one so i would really like to avoid that, any suggestions?
2 queries instead of one is usually not a big deal. You could also just do a composite value(number of likes+the comment) and sort the comments yourself....From stuff I have seen there is never alot of comments except a few posts anyways so that would be very quick.
There are other patterns that might spark ideas here as well...
https://github.com/deanhiller/playorm/wiki/Patterns-Page
Use a composite, where the first component is a long and the second is whatever type is appropriate for your timestamp format. This way the sorting will be correct.
Does anyne know how expression engine deals with a negative offset in a list of channel entries in EE?
as in
offset="-1"
If you use offset="-1" in {exp:channel:entries}, you'll get a major MySQL error (assuming you're logged in as a super admin or are capable of seeing errors).
It's unclear what your goal is from your question. If you expect a negative offset to reverse the order (like PHP string functions), you can use use the opposite sort value. The default is desc, so sort="asc" would be the reverse. Use a positive offset="X" to skip X entries.
If you're expecting an offset like in PHP array_slice where you're still going "forward" but a negative offset starts you X entries from the end, I don't believe there's a direct comparison.
The goal was to work with the preceding chanel entry on the same page as the current channel entry.
I managed to do it instead by pulling out the relevant entry_ids and processing them in php and then put them back in with a fixed_order attribute
I'm using Haystack for search, and the resulting SearchQuerySet returned contains None elements:
>> SearchQuerySet().models(Question, Document, Idea)
>> [<SearchResult: idea.idea (pk=3875)>, None, None, None]
Running rebuild_index doesn't help. If I remove the .models() call from the first line, the problem goes away. I could just filter out None elements from the results, but I wanted to know if this is intended behaviour?
I am using Django 1.4, Whoosh, and Haystack 2.0.0-beta
I had this problem when haystack index had records without corresponding records in DB.
No, it is definitly not the intended behaviour, and as I can see, seems to be related to a design decision in Whoosh. And, as of December 2015, this still seems to be an issue, as can be seen here. Also, I can reproduce it with my setup (django 1.8.5, haystack 2.4.1, Whoosh 2.7.0) - that's why I came here.
Quick and dirty solution that worked for me: Define a new field on your index (type/model/tomato), set it the same for each model, and filter against that value:
.filter(type='my_modelname')
instead of
.models(MyModel).
I don't know (yet) how this scales, but seems to work ok.
Had the same problem using Whoosh, installed Elasticsearch and the None elements went away.