Re: Recreating SOLR index after a schema change - without having to re-post the data
That really is the only way, it would be far easier if you were importing from another source. Are you using solr as a data store? It is not possible via solr to change existing documents in a solr index. It would be a nice feature though. ~Tim. 2009/7/31 Vannia Rajan : > Hi, > > We are using solr-server for a large data-set. We need some changes in > solr schema.xml (datatype change from integer to sint for few fields). It > turns out that the two datatypes (integer and sint) are incompatible and > hence we need to re-index SOLR. > > My question is: > Is there any way by which i can just re-create the index files for > existing data/documents in solr? (without having to re-post the documents) > > I searched through many forums and everything seems to say : "I have to > re-post ALL documents to solr for re-indexing". Please suggest me a better > alternative to achieve my schema-change (I have very large solr-index - > sized around 10GB and it will be tough to query the whole data-set, store it > somewhere as XMLs and then to repost) > > -- > Thanks, > Vanniarajan >
idea of 1.3 release date?
Hi, I was wondering how close Solr 1.3 is to being released. The wiki mentions that August 18th 2008 was the ideal release date. Have there been any release candidates yet? I can't find any on http://lucene.apache.org/solr/ Thanks ~Tim.
Re: idea of 1.3 release date?
ahh, sorry. I should have searched the archives first. I guess it's coming soon then. 2008/9/11 Otis Gospodnetic <[EMAIL PROTECTED]>: > http://markmail.org/search/?q=solr%20release%20candidate > > Otis > > > > > ----- Original Message >> From: Tim Sell <[EMAIL PROTECTED]> >> To: solr-user@lucene.apache.org >> Sent: Thursday, September 11, 2008 6:13:04 AM >> Subject: idea of 1.3 release date? >> >> Hi, >> I was wondering how close Solr 1.3 is to being released. >> The wiki mentions that August 18th 2008 was the ideal release date. >> >> Have there been any release candidates yet? I can't find any on >> http://lucene.apache.org/solr/ >> >> Thanks >> ~Tim. > >
Re: UK Solr users meeting?
+1, would love to attend. I'm in London. 2009/5/18 hbi dev > +1 vote here. We are based in London. > Regards > Waseem > > On Mon, May 18, 2009 at 11:42 AM, Toby Cole > wrote: > > > I know of a few people who'd be interested, we've got quite a few > projects > > using Solr down here in Brighton. > > > > > > On 14 May 2009, at 10:41, Fergus McMenemie wrote: > > > > I was wondering if there is an interest in a UK (South East) solr user > >>> group meeting > >>> > >>> Please let me know if you are interested. I am happy to organize. > >>> > >>> Regards, > >>> > >>> Colin > >>> > >> > >> Yes Very interested. I am in lincolnshire. > >> -- > >> > >> === > >> Fergus McMenemie > >> Email:fer...@twig.me.uk > > > >> Techmore Ltd Phone:(UK) 07721 376021 > >> > >> Unix/Mac/Intranets Analyst Programmer > >> === > >> > > > > Toby Cole > > Software Engineer > > > > Semantico > > Lees House, Floor 1, 21-23 Dyke Road, Brighton BN1 3FE > > T: +44 (0)1273 358 238 > > F: +44 (0)1273 723 232 > > E: toby.c...@semantico.com > > W: www.semantico.com > > > > >
All in one index, or multiple indexes?
Hi, I am wondering if it is common to have just one very large index, or multiple smaller indexes specialized for different content types. We currently have multiple smaller indexes, although one of them is much larger then the others. We are considering merging them, to allow the convenience of searching across multiple types at once and get them back in one list. The largest of the current indexes has a couple of types that belong together, it has just one text field, and it is usually quite short and is similar to product names (words like "The" matter). Another index I would merge with this one, has multiple text fields (also quite short). We of course would still like to be able to get specific types. Is doing filtering on just one type a big performance hit compared to just querying it from it's own index? Bare in mind all these indexes run on the same machine. (we replicate them all to three machines and do load balancing). There are a number of considerations. From an application standpoint when querying across all types we may split the results out into the separate types anyway once we have the list back. If we always do this, is it silly to have them in one index, rather then query multiple indexes at once? Is multiple http requests less significant then the time to post split the results? In some ways it is easier to maintain a single index, although it has felt easier to optimize the results for the type of content if they are in separate indexes. My main concern of putting it all in one index is that we'll make it harder to work with. We will definitely want to do filtering on types sometimes, and if we go with a mashed up index I'd prefer not to maintain separate specialized indexes as well. Any thoughts? ~Tim.
