Hi John,
let me try to recap :
Your Solr Document is an Item with a price as one of the fields, a
purchaseGroupId a groupId.
You filter by purchaseGroupId and then you group by ( or collapse by the
groupId).
At this point how do you want to assign the score ?
For each document in a groupId you want
I found the solution.
http://dzoessolr020:8080/solr4/person/select/?
&q=
(
( ( GenderSFD:Male )
AND {!join from=PersonID to=CoreID fromIndex=personjob
v='((CoCompanyName:"hospital") OR (PoPositionsAllS:"developer"))'}
AND {!join from=DocPersonAttachS to=CoreID fromIndex=document v='(DocNameS:"
: 700ms. The problem is, we are using geofiltering and that is happening *
: before* the queries, so we have to geofilter on the 1B docs to restrict our
: set of docs first, and then do the query on a name field. But it seems that
...
: I've looked at the "cache=false" param, and the "co
Hello Jay,
You can lose some precision in favour of performance: reducing precision of
coordinates (by putting them onto grid) you can increase hit ratio; then
try bbox for faster rough filtration
http://wiki.apache.org/solr/SpatialSearch#bbox_-_Bounding-box_filter
and apply geodist() function in
Thanks for your attention.
I think I was just a little over-worried about search performance,.
Fortunately, solr works pretty nice until present, it's fast enough for me.
2010/1/20 Chris Hostetter
>
> : I have considered building lucene index like:
> : Document: { title, content, author, frien
: I have considered building lucene index like:
: Document: { title, content, author, friends }
That seems like the right appraoch.
: Thus, author and friends are two seperate fields. so I can boost them
: seperately.
: The problem is, if a document's author is the logged-in user, it's uncessar
2010/1/12 Wangsheng Mei
> I have considered building lucene index like:
> Document: { title, content, author, friends }
> Thus, author and friends are two seperate fields. so I can boost them
> seperately.
> The problem is, if a document's author is the logged-in user, it's
> uncessary to search
I have considered building lucene index like:
Document: { title, content, author, friends }
Thus, author and friends are two seperate fields. so I can boost them
seperately.
The problem is, if a document's author is the logged-in user, it's uncessary
to search the friends field, because it would n
