Re: Nested grouping/field collapsing
Hey Martijn, Did you find a good workaround? Rih On Sat, May 28, 2011 at 5:35 AM, Martijn Laarman wrote: > Thanks Mike, > > I've opened https://issues.apache.org/jira/browse/SOLR-2553 for this. > > It's exciting to hear a workable implementation might be possible! > > On Fri, May 27, 2011 at 6:23 PM, Michael McCandless < > luc...@mikemccandless.com> wrote: > > > Can you open a Lucene issue (against the new grouping module) for > > this? > > > > I think this is a compelling use case that we should try to support. > > > > In theory, with the "general" two-pass grouping collector, this should > > be possible, but will require three passes, and we also must > > generalize the 2nd pass collector to accept arbitrary collectors for > > each group (today it's "hardwired" to sort-by-SortField collectors). > > > > I suspect coupling the single-pass grouping collector (currently still > > a patch on LUCENE-3129) with the two-pass collector could also work. > > > > Also, can you describe more details about the two fields you want to > > group/collapse by? > > > > Mike > > > > http://blog.mikemccandless.com > > > > On Fri, May 27, 2011 at 6:13 AM, Martijn Laarman > > wrote: > > > Hi, > > > > > > I was wondering if this issue had already been raised. > > > > > > We currently have a use case where nested field collapsing would be > > really > > > helpful > > > > > > I.e Collapse on field X then Collapse on Field Y within the groups > > returned > > > by field X > > > > > > The current behavior of specifying multiple fields seem to be returning > > > mutiple result sets. > > > > > > Has this already been feature requested ? Does anybody know of a > > workaround > > > ? > > > > > > Many thanks, > > > > > > Martijn > > > > > >
Re: Field collapsing on multiple fields and/or ranges?
Have the same requirement. What is your workaround for this? On Thu, May 12, 2011 at 7:40 AM, arian487 wrote: > I'm wondering if there is a way to get the field collapsing to collapse on > multiple things? For example, is there a way to get it to collapse on a > field (lets say 'domain') but ALSO something else (maybe time or > something)? > > To visualize maybe something like this: > > Group1 has common field 'www.forum1.com' and ALSO the posts are all from > may > 11 > Group2 has common field 'www.forum2.com' and ALSO the posts are all from > may > 11 > . > . > . > GroupX has common field 'www.forum1.com' and ALSO the posts from may 12 > > So obviously it's still sorted by date but it won't group the > 'www.forum1.com' things together if the document is from a different date, > it'll group common date AND common domain field. > > Thanks! > > -- > View this message in context: > http://lucene.472066.n3.nabble.com/Field-collapsing-on-multiple-fields-and-or-ranges-tp2929793p2929793.html > Sent from the Solr - User mailing list archive at Nabble.com. >
Re: Bulk update via filter query
This could work. Are there search/index performance drawbacks when using it? On Mon, May 2, 2011 at 6:22 PM, Ahmet Arslan wrote: > > > Is there an efficient way to update multiple documents with common values > (e.g. color = white)? An example would be to mark all white-colored items > as > sold-out. > > > http://lucene.apache.org/solr/api/org/apache/solr/schema/ExternalFileField.htmlcan > be an option. > >
Bulk update via filter query
Is there an efficient way to update multiple documents with common values (e.g. color = white)? An example would be to mark all white-colored items as sold-out. - Rih
Re: Personalized Search
> > - keep the SOLR index independent of bought/like - have a db table with user prefs on a per item basis I have the same idea this far. at query time, specify boosts for 'my items' items I believe this works if you want to sort results by faved/not faved. But how does it scale if users already favorited/liked hundreds of item? The query can be quite long. Looking forward to your idea. On Thu, May 20, 2010 at 6:37 PM, dc tech wrote: > Another approach would be to do query time boosts of 'my' items under > the assumption that count is limited: > - keep the SOLR index independent of bought/like > - have a db table with user prefs on a per item basis > - at query time, specify boosts for 'my items' items > > We are planning to do this in the context of document management where > documents in 'my (used/favorited ) folders' provide a boost factor > to the results. > > > > On 5/20/10, findbestopensource wrote: > > Hi Rih, > > > > You going to include either of the two field "bought" or "like" to per > > member/visitor OR a unique field per member / visitor? > > > > If it's one or two common fields are included then there will not be any > > impact in performance. If you want to include unique field then you need > to > > consider multi value field otherwise you certainly hit the wall. > > > > Regards > > Aditya > > www.findbestopensource.com > > > > > > > > > > On Thu, May 20, 2010 at 12:13 PM, Rih wrote: > > > >> Has anybody done personalized search with Solr? I'm thinking of > including > >> fields such as "bought" or "like" per member/visitor via dynamic fields > to > >> a > >> product search schema. Another option is to have a multi-value field > that > >> can contain user IDs. What are the possible performance issues with this > >> setup? > >> > >> Looking forward to your ideas. > >> > >> Rih > >> > > > > -- > Sent from my mobile device >
Re: Personalized Search
Well, it's not really a recommendation engine per se but more of a filter for the user. Say, I already own some stuff from the result set, I just want to exclude them from the results. What I'm concerned with is reindexing the document everytime someone marks/votes/likes/boughts. On Thu, May 20, 2010 at 11:04 PM, Ken Krugler wrote: > > On May 19, 2010, at 11:43pm, Rih wrote: > > Has anybody done personalized search with Solr? I'm thinking of including >> fields such as "bought" or "like" per member/visitor via dynamic fields to >> a >> product search schema. Another option is to have a multi-value field that >> can contain user IDs. What are the possible performance issues with this >> setup? >> > > Mitch is right, what you're looking for here is a recommendation engine, if > I understand your question properly. > > And yes, Mahout should work though the Taste recommendation engine it > supports is pretty new. But Sean Owen & Robin Anil have a "Mahout in Action" > book that's in early release via Manning, and it has lots of good > information about Mahout & recommender systems. > > Assuming you have a list of recommendations for a given user, based on > their past behavior and the recommendation engine, then you could use this > to adjust search results. I'm waiting for Hoss to jump in here on how best > to handle that :) > > -- Ken > > > Ken Krugler > +1 530-210-6378 > http://bixolabs.com > e l a s t i c w e b m i n i n g > > > > >
Re: Personalized Search
It will likely be what you suggested, one or two multi value fields. But with 10,000+ members, does Solr scaled with this schema? On Thu, May 20, 2010 at 6:27 PM, findbestopensource < findbestopensou...@gmail.com> wrote: > Hi Rih, > > You going to include either of the two field "bought" or "like" to per > member/visitor OR a unique field per member / visitor? > > If it's one or two common fields are included then there will not be any > impact in performance. If you want to include unique field then you need to > consider multi value field otherwise you certainly hit the wall. > > Regards > Aditya > www.findbestopensource.com > > > > > On Thu, May 20, 2010 at 12:13 PM, Rih wrote: > > > Has anybody done personalized search with Solr? I'm thinking of including > > fields such as "bought" or "like" per member/visitor via dynamic fields > to > > a > > product search schema. Another option is to have a multi-value field that > > can contain user IDs. What are the possible performance issues with this > > setup? > > > > Looking forward to your ideas. > > > > Rih > > >
Personalized Search
Has anybody done personalized search with Solr? I'm thinking of including fields such as "bought" or "like" per member/visitor via dynamic fields to a product search schema. Another option is to have a multi-value field that can contain user IDs. What are the possible performance issues with this setup? Looking forward to your ideas. Rih
