RE: Multiple QParserPlugins, Single RequestHandler

Hi Erik, Thanks for your reply. My particular use case is this: I have an existing QParserPlugin subclass that does some tagging functionality (kind of a group alias thing). This is currently registered with the default queryHandler. I want to add another, quite separate plugin that

RE: Scaling indexes with high document count

Hi, Thanks for your reply (an apologies for the orig msg being ent multiple times to the list - googlemail problems). I actually meant to put 'maxBufferredDocs'. I admit I'm not that familar with this parameter, but as I understand it, it is the number of documents that are held in ram

Scaling indexes with high document count

Hello, I wonder if anyone might have some insight/advice on index scaling for high document count vs size deployments... The nature of the incoming data is a steady stream of, on average, 4GB per day. Importantly, the number of documents inserted during this time is ~7million (i.e. lots of sm

RE: Implementing hierarchical facet

Hi Andy, It sounds like you may want to have a look at tree faceting: https://issues.apache.org/jira/browse/SOLR-792 > Date: Mon, 1 Mar 2010 18:23:51 -0800 > From: angelf...@yahoo.com > Subject: Implementing hierarchical facet > To: solr-user@lucene.apache.org > > I read that a simp

RE: Dynamic Solr indexing

indexes. > > -- > Jan Høydahl - search architect > Cominvent AS - www.cominvent.com > > On 1. mars 2010, at 18.58, Peter S wrote: > > > > > Hi, > > > > > > > > I wonder if anyone could shed some insight on a dynamic indexing > > que

Dynamic Solr indexing

Hi, I wonder if anyone could shed some insight on a dynamic indexing question...? The basic requirement is this: Indexing: A process writes to an index, and when it reaches a certain size (say, 1GB), a new index (core) is 'automatically' created/deployed (i.e. the process doesn't kn

SnapShooter exception during optimize()

Hi, I've been doing some testing with asynchronous index optimization (i.e. performing an optimize in a separate thread while indexing carries on - using its own CommonsHttpSolrServer instance of course :-) -- I've come across this intermittent problem with the snapshooter: 30-Jan-2

RE: Aggregated facet value counts?

his type of need that it'll > "generally" be less arbitrary and locking some things in during > indexing will be the pragmatic way to go for most cases. > > Erik > > > > On Jan 29, 2010, at 9:28 AM, Peter S wrote: > > > > > Well, it woul

RE: Aggregated facet value counts?

omplish that like you're asking. Is the need really to be > arbitrary here? > > Erik > > On Jan 29, 2010, at 7:25 AM, Peter S wrote: > > > > > Hi Erik, > > > > > > > > Thanks for your reply. That's an interesting idea doin

RE: Aggregated facet value counts?

:30:27 -0500 > > When faced with this type of situation where the data is entirely > available at index-time, simply create an aggregated field that glues > the two pieces together, and facet on that. > > Erik > > On Jan 29, 2010, at 6:16 AM, Peter S wrote: > > >

Aggregated facet value counts?

Hi, I was wondering if anyone had come across this use case, and if this type of faceting is possible: The requirement is to build a query such that an aggregated facet count of common (and'ed) field values form the basis of each returned facet count. For example: Let's say I have a

Dedupe of document results at query-time

Hi, I wonder if someone might be able to shed some insight into this problem: Is it possible and/or what is the best/accepted way to achieve deduplication of documents by field at query-time? For example: Let's say an index contains: Doc1 host:Host1 time:1

RE: Reverse sort facet query [SOLR-1672]

> > now i'm totally confused: what are you suggesting this new param would > do, what does the name mean? > Sorry, I wan't clear - there isn't a new parameter, except the one added in the patch. What I was suggesting here is to do the work to remove the new parameter I just put in (facet.sorto

RE: Non-leading wildcard search

like correct behaviour to you? > > If it's correct, that's ok, I'll manage to work 'round it (maybe there's a > way to map the facet field back to the document field?), but if it sounds > wrong, perhaps it warrants further investigation. > > > >

RE: Non-leading wildcard search

> Subject: Re: Non-leading wildcard search > From: yo...@lucidimagination.com > To: solr-user@lucene.apache.org > > On Mon, Jan 4, 2010 at 5:38 PM, Peter S wrote: > > When I query: "Something" or "Something Else" or "*thing" or > > "*omething*"

Non-leading wildcard search

Hello, There are lots of questions and answers in the forum regarding varying wildcard behaviour, but I haven't been able to find any that address this particular behaviour. Perhaps someone could help? Problem: I have a fieldType that only goes through a KeywordTokenizer at index time, to ensure