We have been using 2155 for over 6 months in production with over 2M hits every 10 minutes. No OOM yet.
2155 seems great, and would this issue be any worse than 2155? On Wed, Aug 14, 2013 at 4:08 PM, Jeff Wartes <jwar...@whitepages.com> wrote: > > Hm, "Give me all the stores that only have branches in this area" might be > a plausible use case for farthest distance. > That's essentially a "contains" question though, so maybe that's already > supported? I guess it depends on how contains/intersects/etc handle > multi-values. I feel like multi-value interaction really deserves its own > section in the documentation. > > > I'm aware of the memory issue, but it seems like if you want sort > multi-valued points, it's either this or try to pull in the 2155 patch. In > general I'd rather go with the thing that's being maintained. > > > Thanks for the code pointer. You're right, that doesn't look like > something I can easily use for more general aggregate scoring control. Ah > well. > > > > On 8/14/13 12:35 PM, "Smiley, David W." <dsmi...@mitre.org> wrote: > > > > > > >On 8/14/13 2:26 PM, "Jeff Wartes" <jwar...@whitepages.com> wrote: > > > >> > >>I'm still pondering aggregate-type operations for scoring multi-valued > >>fields (original thread: http://goo.gl/zOX53f ), and it occurred to me > >>that distance-sort with SpatialRecursivePrefixTreeFieldType must be doing > >>something like that. > > > >It isn't. > > > >> > >>Somewhat surprisingly I don't see this in the documentation anywhere, but > >>I presume the example query: (from: > >>http://wiki.apache.org/solr/SolrAdaptersForLuceneSpatial4) > >>"q={!geofilt score=distance sfield=geo pt=54.729696,-98.525391 d=10}" > >> > >>assigns the distance/score based on the *closest* lat/long if the sfield > >>is a multi-valued field. > > > >Yes it does. > > > >> > >>That's a reasonable default, but it's a bit arbitrary. Can I sort based > >>on > >>the *furthest* lat/long in the document? Or the average distance? > >> > >>Anyone know more about how this works and could give me some pointers? > > > >I considered briefly supporting the farthest distance but dismissed it as > >I saw no real use-case. I didn't think of the average distance; that's > >plausible. Any way, you're best bet is to dig into the code. The > >relevant part is ShapeFieldCacheDistanceValueSource. > > > >FYI something to keep in mind: > >https://issues.apache.org/jira/browse/LUCENE-4698 > > > >~ David > > > > -- Bill Bell billnb...@gmail.com cell 720-256-8076
