On Thu, Sep 9, 2010 at 21:00, Lance Norskog <goks...@gmail.com> wrote: > I just checked out the trunk, and branch 3.x This query is accepted on both, > but gives no responses: > http://localhost:8983/solr/select/?q=*:*&sort=dist(2,x_dt,y_dt,0,0)+asc
So you are saying when you add the sort parameter you get no results back, but do not get the error I am seeing? Should I open a Jira ticket? > x_dt and y_dt are wildcard fields with the tdouble type. "tdouble" > explicitly says it is stored and indexed. Your 'longitude' and 'latitude' > fields may not be stored? No, they are stored. http://localhost:8983/solr/select?q=*:*&rows=1&wt=xml&indent=true <?xml version="1.0" encoding="UTF-8"?> <response> <lst name="responseHeader"> <int name="status">0</int> <int name="QTime">9</int> </lst> <result name="response" numFound="365775" start="0"> <doc> ... <double name="latitude">47.6636</double> <double name="longitude">-122.3054</double> > Also, this is accepted on both branches: > http://localhost:8983/solr/select/?q=*:*&sort=sum(1)+asc > > The documentation for sum() does not mention single-argument calls. This also fails http://localhost:8983/solr/select/?q=*:*&sort=sum(1,2)+asc http://localhost:8983/solr/select/?q=*:*&sort=sum(latitude,longitude)+asc > Scott K wrote: >> >> According to the documentation, sorting by function has been a feature >> since Solr 1.5. It seems like a major regression if this no longer >> works. >> http://wiki.apache.org/solr/FunctionQuery#Sort_By_Function >> >> The _val_ trick does not seem to work if used with a query term, >> although I can try some more things to give 0 value to the query term. >> >> On Wed, Sep 8, 2010 at 22:21, Lance Norskog<goks...@gmail.com> wrote: >> >>> >>> It says that the field "sum(1)" is not indexed. You don't have a field >>> called 'sum(1)'. I know there has been a lot of changes in query parsing, >>> and sorting by functions may be on the list. But the _val_ trick is the >>> older one and, and you noted, still works. The _val_ trick sets the >>> ranking >>> value to the output of the function, thus indirectly doing what sort= >>> does. >>> >>> Lance >>> >>> Scott K wrote: >>> >>>> >>>> I get the error on all functions. >>>> GET 'http://localhost:8983/solr/select?q=*:*&sort=sum(1)+asc' >>>> Error 400 can not sort on unindexed field: sum(1) >>>> >>>> I tried another nightly build from today, Sep 7th, with the same >>>> results. I attached the schema.xml >>>> >>>> Thanks for the help! >>>> Scott >>>> >>>> On Wed, Sep 1, 2010 at 18:43, Lance Norskog<goks...@gmail.com> wrote: >>>> >>>> >>>>> >>>>> Post your schema. >>>>> >>>>> On Mon, Aug 30, 2010 at 2:04 PM, Scott K<s...@skister.com> wrote: >>>>> >>>>> >>>>>> >>>>>> The new spatial filtering (SOLR-1586) works great and is much faster >>>>>> than fq={!frange. However, I am having problems sorting by distance. >>>>>> If I try >>>>>> GET >>>>>> >>>>>> 'http://localhost:8983/solr/select/?q=*:*&sort=dist(2,latitude,longitude,0,0)+asc' >>>>>> I get an error: >>>>>> Error 400 can not sort on unindexed field: >>>>>> dist(2,latitude,longitude,0,0) >>>>>> >>>>>> I was able to work around this with >>>>>> GET 'http://localhost:8983/solr/select/?q=*:* AND _val_:"recip(dist(2, >>>>>> latitude, longitude, 0,0),1,1,1)"&fl=*,score' >>>>>> >>>>>> But why isn't sorting by functions working? I get this error with any >>>>>> function I try to sort on.This is a nightly trunk build from Aug 25th. >>>>>> I see SOLR-1297 was reopened, but that seems to be for edge cases. >>>>>> >>>>>> Second question: I am using the LatLonType from the Spatial Filtering >>>>>> wiki, http://wiki.apache.org/solr/SpatialSearch >>>>>> Are there any distance sorting functions that use this field, or do I >>>>>> need to have three indexed fields, store_lat_lon, latitude, and >>>>>> longitude, if I want both filtering and sorting by distance. >>>>>> >>>>>> Thanks, Scott >>>>>> >>>>>> >>>>>> >>>>> >>>>> -- >>>>> Lance Norskog >>>>> goks...@gmail.com >>>>> >>>>> >>>>> >>> >>> >
