Thanks David, I'm not clear on how the X value of a range pair will help me
filter on pairs of start-end times.Can you explain how that'd work? Still,
seems like the ability to create subobjects in solr is a huge feature, I'm
hoping it'll eventually make it in.Eric.
> From: dsmi...@mitre.org
> To: solr-user@lucene.apache.org
> Subject: Re: Solr 4.0 - Join performance
> Date: Tue, 14 Aug 2012 20:50:43 +0000
>
> This one should work for now:
> https://issues.apache.org/jira/browse/SOLR-3304
> If you're comfortable with checking out Lucene/Solr and applying a patch,
> then you can do it yourself and get it working without any real coding.
> You'd have to use a dummy constant value for 'y' as you index rectangles, and
> you'd configure it for non-geospatial. The unfortunate piece is that 'x'
> (nor 'y') can't be the full range of a double, and it's not oriented towards
> a 'long' time value. There's no JIRA issue for a one-dimensional spatial
> field yet; that's pretty far down the priority list. You are certainly not
> the first that could use this feature, though.
>
> ~ David Smiley
>
> On Aug 14, 2012, at 4:19 PM, Eric Khoury wrote:
>
> >
> > Thanks David, that does indeed sound like it'll help. Is there an issue
> > number I can use to track development\availability?Eric.
> >> From: dsmi...@mitre.org
> >> To: solr-user@lucene.apache.org
> >> Subject: Re: Solr 4.0 - Join performance
> >> Date: Tue, 14 Aug 2012 20:15:27 +0000
> >>
> >> Stepping back a bit, the reason you are using multiple cores with a join
> >> is because Solr doesn't have a multi-valued numeric range type. The
> >> spatial work I'm doing in Lucene-spatial does, and it's 2-dimensional for
> >> an x & y whereas your case calls for one dimension. It's taking a bit of
> >> time, but when finished you should be able to use it for your use case
> >> ignoring the 'y'. Eventually I'd like to develop such a Solr field type
> >> for a numeric/time range to do it more natively but that's a ways off.
> >>
> >> Cheers,
> >> ~ David Smiley
> >>
> >> On Aug 2, 2012, at 10:45 AM, Eric Khoury wrote:
> >>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>> Hello all,
> >>>
> >>>
> >>>
> >>> I’m testing out the new join feature, hitting some perf
> >>> issues, as described in Erick’s article
> >>> (http://architects.dzone.com/articles/solr-experimenting-join).
> >>>
> >>> Basically, I’m using 2 objects in solr (this is a simplified
> >>> view):
> >>>
> >>>
> >>>
> >>> Item
> >>>
> >>> - Id
> >>>
> >>> - Name
> >>>
> >>>
> >>>
> >>> Grant
> >>>
> >>> - ItemId
> >>>
> >>> - AvailabilityStartTime
> >>>
> >>> - AvailabilityEndTime
> >>>
> >>>
> >>>
> >>> Each item can have multiple grants attached to it.
> >>>
> >>>
> >>>
> >>> The query I'm using is the following, to find items by
> >>> name, filtered by grants availability window:
> >>>
> >>>
> >>>
> >>> solr/select?fq=Name:XXX&q={!join
> >>> from=ItemId to=Id} AvailabilityStartTime:[* TO NOW] AND
> >>> -AvailabilityEndTime:[*
> >>> TO NOW]
> >>>
> >>>
> >>>
> >>> With a hundred thousand items, this query can take multiple seconds
> >>> to perform, due to the large number or ItemIds returned from the join
> >>> query.
> >>>
> >>> Has anyone come up with a better way to use joins for these types of
> >>> queries? Are there improvements planned in 4.0 rtm in this area?
> >>>
> >>>
> >>>
> >>> Btw, I’ve explored simply adding Start-End times to items, but
> >>> the flat data model makes it hard to maintain start-end pairs.
> >>>
> >>>
> >>>
> >>> Thanks for the help!
> >>>
> >>> Eric.
> >>>
> >>>
> >>>
> >>>
> >>
> >
>
