Re: Index field untokenized

: I want to index some data untokenized (e.g. url), but I can't : find a way to do it. : : I know there is a way to do it in solr configuration but I want : to specify this options directly in my solr xml. : : This is a fragment of the xml that i post in slr and I want to know if is : possible t

RE: Index an entire Phrase and not it's constituent parts?

I'm sorry for doubleposting: Drinking a coup of coffee was a good idea. KeepWordFilter seems to mean, that you give a Set of words to it. Everything that is not in the set, will be deleted. Furthermore, the description is correct, since it really behaves like an inversion of StopWordFilter. -- Vi

RE: Index an entire Phrase and not it's constituent parts?

Hmm, I don't understand the problem. Look: If your analyzer looks like: And your document would looks like: "There is a big performance issue. Solving the problem would be great. As long as we try to give our best, ..." After the LowerCaseFilterFactory every

Re: Index an entire Phrase and not it's constituent parts?

y be I should try solr.KeepWordFilterFactory if it can deal with > phrases . . ? > > I'm stumped =( > > -Original Message----- > From: MitchK [mailto:mitc...@web.de] > Sent: Saturday, March 13, 2010 8:12 AM > To: solr-user@lucene.apache.org > Subject: RE: Index

RE: Index an entire Phrase and not it's constituent parts?

? I'm stumped =( -Original Message- From: MitchK [mailto:mitc...@web.de] Sent: Saturday, March 13, 2010 8:12 AM To: solr-user@lucene.apache.org Subject: RE: Index an entire Phrase and not it's constituent parts? Christopher, maybe the SynonymFilter can help you to solve your problem. Let

RE: Index an entire Phrase and not it's constituent parts?

Christopher, maybe the SynonymFilter can help you to solve your problem. Let me try to explain: If you create an extra field in the index for your use-case, you can boost matches of them in a special way. The next step is creating an extra synonym-file. as much as => SpecialPhrase1 in amount o

RE: Index an entire Phrase and not it's constituent parts?

oups formation 'as' we had expected 'in' December." Let me know if that clarifies or not. Most grateful, Christopher -Original Message- From: Erick Erickson [mailto:erickerick...@gmail.com] Sent: Tuesday, March 09, 2010 7:52 PM To: solr-user@lucene.apache.org Subject: Re: I

Re: index merge

Hi All, Thank you for the very valuable suggestions. I am planning to try using the Master - Slave configuration. Best Rgds, Mark. On Mon, Mar 8, 2010 at 11:17 AM, Mark Miller wrote: > On 03/08/2010 10:53 AM, Mark Fletcher wrote: > >> Hi Shalin, >> >> Thank you for the mail. >> My main purpose

Re: Index an entire Phrase and not it's constituent parts?

t; >> >> Feel like I must be missing something . . . but can't figure out what. >> >> >> >> Do I really need to write a custom analyzer for this? >> >> >> >> _ >> >> From Erick Erickson Subject Re:

Re: Index an entire Phrase and not it's constituent parts?

gt; > Feel like I must be missing something . . . but can't figure out what. > > > > Do I really need to write a custom analyzer for this? > > > > _ > > From Erick Erickson Subject Re: Index an entire > Phrase and not it's constituent parts? Date

RE: Index an entire Phrase and not it's constituent parts?

. Do I really need to write a custom analyzer for this? _ >From Erick Erickson Subject Re: Index an entire Phrase and not it's constituent parts? Date Thu, 04 Mar 2010 19:55:58 GMT Try KeywordTokenizerFactory. This page is very useful: http://wiki.apache.org/solr/AnalyzersToke

Re: index merge

On 03/08/2010 10:53 AM, Mark Fletcher wrote: Hi Shalin, Thank you for the mail. My main purpose of having 2 identical cores COREX - always serves user request COREY - every day once, takes the updates/latest data and passess it on to COREX. is:- Suppose say I have only one COREY and suppose a r

Re: index merge

Hi Mark, On Mon, Mar 8, 2010 at 9:23 PM, Mark Fletcher wrote: > > My main purpose of having 2 identical cores > COREX - always serves user request > COREY - every day once, takes the updates/latest data and passess it on to > COREX. > is:- > > Suppose say I have only one COREY and suppose a reque

Re: index merge

Hi Shalin, Thank you for the mail. My main purpose of having 2 identical cores COREX - always serves user request COREY - every day once, takes the updates/latest data and passess it on to COREX. is:- Suppose say I have only one COREY and suppose a request comes to COREY while the update of the l

Re: index merge

Hi Mark, On Mon, Mar 8, 2010 at 7:38 PM, Mark Fletcher wrote: > > I ran the SWAP command. Now:- > COREX has the dataDir pointing to the updated dataDir of COREY. So COREX > has the latest. > Again, COREY (on which the update regularly runs) is pointing to the old > index of COREX. So this now doe

Re: index merge

Hi Shalin, Thank you for the reply. I got your point. So I understand merge will just duplicate things. I ran the SWAP command. Now:- COREX has the dataDir pointing to the updated dataDir of COREY. So COREX has the latest. Again, COREY (on which the update regularly runs) is pointing to the old

Re: index merge

Hi Mark, On Sun, Mar 7, 2010 at 6:20 PM, Mark Fletcher wrote: > > I have created 2 identical cores coreX and coreY (both have different > dataDir values, but their index is same). > coreX - always serves the request when a user performs a search. > coreY - the updates will happen to this core an

Re: Index an entire Phrase and not it's constituent parts?

Try KeywordTokenizerFactory. This page is very useful: http://wiki.apache.org/solr/AnalyzersTokenizersTokenFilters HTH Erick On Thu, Mar 4, 2010 at 2:31 PM, Christopher Ball < christopher.b...@metaheuristica.com> wrote: > How can I Ind

Re: Re-index after Solr config file changed without restarting services

Marc, At least for the "force Solr to reindex" part, I think you'll need to index yourself. That is, you need to run whatever app you run when you (re)index the data normally. Solr won't automagically reindex the data. Otis Sematext :: http://sematext.com/ :: S

Re-index after Solr config file changed without restarting services

file and after committing the changes, force Solr to re-index based on those changes without restarting Tomcat. I have configured a Solr Master and Slave, each of which has a single core: * http://master:8080/solr/core * http://slave:8080/solr/core The cores are defined in

Re: Index size

Hi, All the document can be up to 10K. Most if it comes from a single field which is both indexed and stored. The data is uncompressed because it would eat up to much CPU considering the volume we have. We have around 30 fields in all. We also need to compute some facets as well as collapse the

Re: Index size

It depends on many factors - how big those docs are (compare a tweet to a news article to a book chapter) whether you store the data or just index it, whether you compress it, how and how much you analyze the data, etc. Otis Sematext :: http://sematext.com/ :: Solr - Lucene - Nutch Hadoop e

RE: Index Courruption after replication by new Solr 1.4 Replication

ile a bug? Thanks, Osborn -Original Message- From: Osborn Chan [mailto:oc...@shutterfly.com] Sent: Friday, January 15, 2010 12:35 PM To: solr-user@lucene.apache.org Subject: RE: Index Courruption after replication by new Solr 1.4 Replication Hi Otis, Thanks. There is no NFS anymore, a

Re: index of facet fields are not same as original string

Hi Lance, I created a new fieldtype with solr.KeywordTokenizerFactory class in analyser and it worked for me. Thanks for all your help. Regards, Uma Lance Norskog-2 wrote: > > After you change the schema.xml file, you have to rebuild the index > completely. At that point, g_number fields sh

Re: index of facet fields are not same as original string

After you change the schema.xml file, you have to rebuild the index completely. At that point, g_number fields should not be stemmed. You can examine what these text field types do. http://wiki.apache.org/solr/FAQ#My_search_returns_too_many_.2BAC8_too_little_.2BAC8_unexpected_results.2C_how_to_de

Re: index of facet fields are not same as original string

Hi Sergey, In schema.xml, i have got by default ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M ^M and i added following entry in schema.xml file, But it didnt help. Still the texts are

Re: index of facet fields are not same as original string

facets are based off the indexed version of your string nor the stored version, you probably have an analyzer thats removing punctuation, most people index the same field multiple ways for different purposes, matching. storting, faceting etc... index a copy of your field as string type and facet o

Re: index of facet fields are not same as original string

Hi, probably, it's because of stemming if you need unstemmed text you can use 'textgen' data type for the field Sergey On Thu, Jan 28, 2010 at 12:25 PM, Solr user wrote: > > Hi, > > I am new to Solr. I found facets fields does not reflect the original > string in the record. For example, > > t

Re: Index gets deleted after commit?

DIH is the DataImportHandler. Please consult the two URLs http://wiki.apache.org/solr/DataImportHandler and http://wiki.apache.org/solr/DataImportHandlerFaq for further information. Cheers, Sven --On Monday, January 25, 2010 11:33:59 AM +0200 Bogdan Vatkov wrote: Hi Amit, What is D

Re: Index gets deleted after commit?

Hi Amit, What is DIH? (I am Solr newbie). In the mean time I resolved my issue - it was very stupid one - on of the files in my folder with XMLs (that I send to Solr with the SimplePostTool), and actually the latest created one (so it got executed last each time I run the folder), contaoned *:*..

Re: Index gets deleted after commit?

Are you using the DIH? If so, did you try setting clean=false in the URL line? That prevents wiping out the index on load. On Jan 23, 2010 4:06 PM, "Bogdan Vatkov" wrote: After mass upload of docs in Solr I get some "REMOVING ALL DOCUMENTS FROM INDEX" without any explanation. I was running inde

Re: Index Courruption after replication by new Solr 1.4 Replication

: Subject: Index Courruption after replication by new Solr 1.4 Replication : References: <3ca90cc651ae3f4baedf8a5b78639c8c038a1...@mail02.tveyes.com> : <667725.5147...@web52905.mail.re2.yahoo.com> : <3ca90cc651ae3f4baedf8a5b78639c8c038a1...@mail02.tveyes.com> : <359a92831001151042n73a47daby46ee

RE: Index Courruption after replication by new Solr 1.4 Replication

, 2010 12:31 PM To: solr-user@lucene.apache.org Subject: Re: Index Courruption after replication by new Solr 1.4 Replication This is not a direct answer to your question, but can you avoid NFS? My first guess would be that NFS somehow causes this problem. If you check the ML archives for: NFS

Re: Index Courruption after replication by new Solr 1.4 Replication

This is not a direct answer to your question, but can you avoid NFS? My first guess would be that NFS somehow causes this problem. If you check the ML archives for: NFS lock , you will see what I mean. Otis -- Sematext -- http://sematext.com/ -- Solr - Lucene - Nutch - Original Message

Re: Deleting * and Re-index after schema change

I'd look at the DataImportHandler console and try using some debugging there to track down why only one document. I suspect it's a configuration issue of your SQL query not picking up everything you expect. Erik On Jan 12, 2010, at 9:33 AM, Lee Smith wrote: Hi Erik Done as sugg

Re: Deleting * and Re-index after schema change

Dont worry my bad. I made a mistake in my dataimport to all have the same ID ! All working now thank you On 12 Jan 2010, at 14:33, Lee Smith wrote: > Hi Erik > > Done as suggested and still only showing 1 Document > > Doing a *:* give me 1 document > > Cant understand why ? > > On 12 Jan

Re: Deleting * and Re-index after schema change

Hi Erik Done as suggested and still only showing 1 Document Doing a *:* give me 1 document Cant understand why ? On 12 Jan 2010, at 14:25, Erik Hatcher wrote: > What does a search of *:* give you? > > As far as your steps, delete the index folder *before* restarting Solr, not > after. That

Re: Deleting * and Re-index after schema change

What does a search of *:* give you? As far as your steps, delete the index folder *before* restarting Solr, not after. That might be the issue. Erik On Jan 12, 2010, at 9:23 AM, Lee Smith wrote: Am I doing this right. I have made changes to my schema so as per guide I done the f

Deleting * and Re-index after schema change

Am I doing this right. I have made changes to my schema so as per guide I done the following. Stopped the application Updated the Schema Re-Started Deleted the index folder Then ran a full import & optimize command ie: /dataimport?command=full-import&optimize=true In the status it shows Indexi

Re: Index Splitter

Koji Sekiguchi wrote: Giovanni Fernandez-Kincade wrote: You can't really use this if you have an optimized index, right? For optimized index, I think you can use MultiPassIndexSplitter. Correct - MultiPassIndexSplitter can handle any index - optimized or not, with or without deletions, e

Re: Index Splitter

Giovanni Fernandez-Kincade wrote: You can't really use this if you have an optimized index, right? For optimized index, I think you can use MultiPassIndexSplitter. Koji -- http://www.rondhuit.com/en/

RE: Index Splitter

You can't really use this if you have an optimized index, right? -Original Message- From: Koji Sekiguchi [mailto:k...@r.email.ne.jp] Sent: Tuesday, November 24, 2009 6:57 PM To: solr-user@lucene.apache.org Subject: Re: Index Splitter Giovanni Fernandez-Kincade wrote: > Hi, >

Re: Index Splitter

Giovanni Fernandez-Kincade wrote: Hi, I've heard about a tool that can be used to split Lucene indexes, for cases where you want to break up a large index into shards. Do you know where I can find it? Any observations/recommendations about its use? This seems promising but I'm not sure if ther

Re: Index time boosting troubles

: I had working index time boosting on documents like so: : : Everything was great until I made some changes that I thought where no : related to the doc boost but after that my doc boosting appears to be : missing. : : I'm having a tough time debugging this and didn't have the sense to version

Re: Index time boosts, payloads, and long query strings

Yep On Mon, Nov 23, 2009 at 4:13 AM, Girish Redekar wrote: > Thanks Erick! > > After reading your answer, and re-reading the Solr wiki, I realized my > folly. I used to think that index-time boosts when applied on a per-field > basis are equivalent to query time boosts to that field. > > To

Re: Index time boosts, payloads, and long query strings

Thanks Erick! After reading your answer, and re-reading the Solr wiki, I realized my folly. I used to think that index-time boosts when applied on a per-field basis are equivalent to query time boosts to that field. To ensure that my new understanding is correct , I'll state it in my words. Index

Re: Index time boosts, payloads, and long query strings

I still think they are apples and oranges. If you boost *all* titles, you're effectively boosting none of them. Index time boosting expresses "this document's title is more important than other document titles." What I think you're after is "titles are more important than other parts of the documen

Re: Index time boosts, payloads, and long query strings

Hi Erick - Maybe I mis-wrote. My question is: would "title:any_query^4.0" be faster/slower than applying index time boost to the field title. Basically, if I take *every* user query and search for it in title with boost (say, 4.0) - is it different than saying field title has boost 4.0? Cheers,

Re: Index time boosts, payloads, and long query strings

I'll take a whack at index .vs. query boosting. They are expressing very different concepts. Let's claim we're interested in boosting the title field Index time boosting is expressing "this document's title is X more important than a normal document title". It doesn't matter *what* the title

Re: index-time boost ... query

No, the reverse is true. Sorting is very very fast in Lucene. The first sort operation spends a lot of time making a data structure and then following sort calls use it. On Thu, Nov 19, 2009 at 1:52 PM, Anil Cherian wrote: > Hi David, > > I just now tried a sorting on the results and I got the re

RE: Index documents with Solr

Glock, did you get this approach to work? let me know. Thanks, Glock, Thomas wrote: > > I have a similar situation but not expecting any easy setup. Currently > the tables contain both a url to the file and quite a bit of additional > metadata about the file. I'm planning one initial load to

Re: index-time boost ... query

Hi David, I just now tried a sorting on the results and I got the records with latest approval_dt first. My question now is will index-time boosting method increase the response. ie will I be able to acheive the same thing i achieved using sorting much faster if i use index-time boosting. If you

Re: index-time boost ... query

Hi David, Thank you for the mail. It seems you are right.sorting might solve the issue as it is not giving any special weightage to any record other than its approval_dt is the latest one.. I think i am convinced for now. I am eagerly waiting for your book around thanks giving so taht i can

Re: index-time boost ... query

Anil, without delving into why your boosting isn't working as you expect, why don't you simply sort? Based on a message you sent to me directly (excerpted bellow), it seems you want sorting, not boosting. You could subsequently sort by score after approval_dt. ~ David Smiley Author: http://ww

Re: Index-time field boosting not working?

Hi Ian. Thanks for buying my book. The "boost" attribute goes on the field for the XML message you're sending to Solr. In your example you mistakenly placed it in the schema. FYI I use index time boosting as well as query time boosting. Although index time boosting isn't something I can chan

RE: Index-time field boosting not working?

esign :( If you or anyone else here has any historical perspective on this, I'd be interested to hear about it. Regards, Ian, -Original Message- From: Otis Gospodnetic [mailto:otis_gospodne...@yahoo.com] Sent: 18 November 2009 22:55 To: solr-user@lucene.apache.org Subject: Re: Index-

Re: Index-time field boosting not working?

Can "boost" attribute really be specified for a field in the schema? I wasn't aware of that, and I don't see it on http://wiki.apache.org/solr/SchemaXml . Maybe you are mixing it with http://wiki.apache.org/solr/UpdateXmlMessages#Optional_attributes_for_.22field.22 ? Otis -- Sematext is hirin

Re: index size before and after commit

Ha! Searching "partial optimize" on http://www.lucidimagination.com/search , we discover SOLR-603 which gives the 'maxSegments' option to the command. The text does not include the word 'partial'. It's on http://wiki.apache.org/solr/UpdateXmlMessages. The command gives a number of Lucene segments

Re: index size before and after commit

I've heard there is a new "partial optimize" feature in Lucene, but it is not mentioned in the Solr or Lucene wikis so I cannot advise you how to use it. On a previous project we had a 500GB index for 450m documents. It took 14 hours to optimize. We found that Solr worked well (given enough RAM fo

Re: index size before and after commit

I've now worked on three different search engines and they all have a 3X worst case on space, so I'm familiar with this case. --wunder On Oct 1, 2009, at 7:15 AM, Mark Miller wrote: Nice one ;) Its not technically a case where optimize requires > 2x though in case the user asking gets confuse

Re: index size before and after commit

bq. and reindex without any merges. Thats actually quite a hoop to jump as well - though if you determined and you have tons of RAM, its somewhat doable. Mark Miller wrote: > Nice one ;) Its not technically a case where optimize requires > 2x > though in case the user asking gets confused. Its a

Re: index size before and after commit

Nice one ;) Its not technically a case where optimize requires > 2x though in case the user asking gets confused. Its a case unrelated to optimize that can grow your index. Then you need < 2x for the optimize, since you won't copy the deletes. It also requires that you jump hoops to delete everyth

Re: index size before and after commit

Here is how you need 3X. First, index everything and optimize. Then delete everything and reindex without any merges. You have one full-size index containing only deleted docs, one full- size index containing reindexed docs, and need that much space for a third index. Honestly, disk is che

Re: index size before and after commit

Whoops - they way I have mail come in, not easy to tell if I'm replying to Lucene or Solr list ;) The way Solr works with Searchers and reopen, it shouldn't run into a situation that requires greater than 2x to optimize. I won't guarantee it ;) But based on what I know, it shouldn't happen under n

Re: index size before and after commit

Phillip Farber wrote: > I am trying to automate a build process that adds documents to 10 > shards over 5 machines and need to limit the size of a shard to no > more than 200GB because I only have 400GB of disk available to > optimize a given shard. > > Why does the size (du) of an index typically

Re: index size before and after commit

It may take some time before resources are released and garbage collected, so that may be part of the reason why things hang around and du doesn't report much of a drop. On Oct 1, 2009, at 8:54 AM, Phillip Farber wrote: I am trying to automate a build process that adds documents to 10 shar

Re: Index backup with new replication?

Yep, super straight-forward, thanks a bunch! Guess I missed this piece of the wiki, looks like its going through alot of updates towards solr 1.4 release.. thanks, -Chak ryguasu wrote: > > The documentation could maybe be improved, but the basics of backup > snapshots with the in-process (Java

Re: Index backup with new replication?

The documentation could maybe be improved, but the basics of backup snapshots with the in-process (Java-based) replication handler actually seem pretty straightforward to me, now that I understand it: 1. You can make a snapshot whenever you want by hitting http://master_host:port/solr/replication?

Re: Index health checking

See http://issues.apache.org/jira/browse/SOLR-566. Patches welcome. On Aug 18, 2009, at 7:46 AM, Licinio Fernández Maurelo wrote: As you suppose, i'm asking if currently solr implements this functionality or there is any related jira issue. A few days ago, our solr server suffered an unsafe p

Re: Index rebuilding.

On Wed, Aug 5, 2009 at 8:21 PM, caezar wrote: > > Hi All, > > Am I right, when I say, that solr index is rebuild, when 'commit' command > send? > Let's suppose yes. For instance, I have solr index with 1M document, and > then I'm committing one more million documents. Here is some questions: > -

Re: index backup works only if there are committed index

I agree. I think both options could be useful - perhaps a 'forceBackup' as well? Documentation would take care of the rest. Have you added this info to the wiki yet? -- - Mark http://www.lucidimagination.com On Thu, Jul 23, 2009 at 12:56 PM, solr jay wrote: > Hi, > > I noticed that the backup

Re: Index per user - thousands of indices in one Solr instance

On Jul 23, 2009, at 7:00 AM, Łukasz Osipiuk wrote: See https://issues.apache.org/jira/browse/SOLR-1293 We're planning to put up a patch soon. Perhaps we can collaborate? What are your estimations to have this patches ready. We have quite tight deadlines and cannot afford months of development

Re: Index per user - thousands of indices in one Solr instance

The patch is up on SOLR-1293. There's a wiki page at http://wiki.apache.org/solr/LotsOfCores with details on the changes and configuration. On Thu, Jul 23, 2009 at 4:51 PM, Shalin Shekhar Mangar < shalinman...@gmail.com> wrote: > On Thu, Jul 23, 2009 at 4:30 PM, Łukasz Osipiuk wrote: > >> >> > Se

Re: index backup works only if there are committed index

Another options is making backups more directly, not using the Solr backup mechanism. Check the green link on http://www.manning.com/hatcher3/ Otis -- Sematext is hiring -- http://sematext.com/about/jobs.html?mls Lucene, Solr, Nutch, Katta, Hadoop, HBase, UIMA, NLP, NER, IR - Original Me

Re: Index per user - thousands of indices in one Solr instance

On Thu, Jul 23, 2009 at 4:30 PM, Łukasz Osipiuk wrote: > > > See https://issues.apache.org/jira/browse/SOLR-1293 > > > > We're planning to put up a patch soon. Perhaps we can collaborate? > > What are your estimations to have this patches ready. We have quite > tight deadlines > and cannot afford

Re: Index per user - thousands of indices in one Solr instance

On Thu, Jul 23, 2009 at 11:44, Shalin Shekhar Mangar wrote: > On Thu, Jul 23, 2009 at 3:06 PM, Łukasz Osipiuk wrote: > >> >> I am new to Solr and I want to get a quick hint if it is suitable for >> what we want to use it for. >> We are building e-mail platform and we want to provide our users with

Re: Index per user - thousands of indices in one Solr instance

On Thu, Jul 23, 2009 at 3:06 PM, Łukasz Osipiuk wrote: > > I am new to Solr and I want to get a quick hint if it is suitable for > what we want to use it for. > We are building e-mail platform and we want to provide our users with > full-text search functionality. > > We are not willing to use si

Re: index version on slave

oh, in case of index data corrupted on slave, I want to download the entire index from master. During downloading, I want the slave be out of service and put it back after it finished. I was trying figure out how to determine downloading is done. Right now, I am calling http://slave_host:8983/solr

Re: index version on slave

on the slave this command would not work well. The indexversion is not the actual index version. It is the current replicateable index version. why do you call that API directly? On Tue, Jul 21, 2009 at 12:53 AM, solr jay wrote: > If you ask for the index version of a slave instance, you always

Re: Index-time boost propagated to copyField?

Mat Brown wrote: Hi all, If I have two fields that are copied into a copyField, and I index data in these fields using different index-time boosts, are those boosts propagated into the copyField? Thanks! Mat No, but the norms of source fields of copyField are "propagated" into the destinat

Re: Index partitioning with solr multiple core feature

Shalin, First of all each entity data is unrelated so it makes sense to use solr core concept as per your suggestion. But Since you are suggesting putting each entity index on same box will consume CPU so does it make sense to add boxes based on number of entities considering i will have to add re

Re: Index partitioning with solr multiple core feature

On Mon, Jul 6, 2009 at 3:05 PM, Sumit Aggarwal wrote: > Hi Shalin, > Yes i want to achieve a logical separation of indexes for performance > reason > also else index size will keep on growing as i have 8 different entities. I > am already partitioning all these entities to different servers also o

Re: Index partitioning with solr multiple core feature

Shalin, at a time i will be doing search only on one entity... Also data will be indexed only to corresponding entity. Thanks, Sumit On Mon, Jul 6, 2009 at 3:05 PM, Sumit Aggarwal wrote: > Hi Shalin, > Yes i want to achieve a logical separation of indexes for performance > reason also else index

Re: Index partitioning with solr multiple core feature

Hi Shalin, Yes i want to achieve a logical separation of indexes for performance reason also else index size will keep on growing as i have 8 different entities. I am already partitioning all these entities to different servers also on which i will be doing search based on distributed search by sol

Re: Index partitioning with solr multiple core feature

On Mon, Jul 6, 2009 at 1:40 PM, Sumit Aggarwal wrote: > I was trying to implement entity based partitioning using multiple core > feature. > So my solr.xml is like : > > > > > > > > > > > > Now using http://localhost:8983/solr/User/ or > http://localhost:8983/solr/Group/ i am able to rea

Re: Index partitioning with solr multiple core feature

I forgot to mention i already have a partitioning to 3 different servers for each entity based on some unique int value. On Mon, Jul 6, 2009 at 1:40 PM, Sumit Aggarwal wrote: > I was trying to implement entity based partitioning using multiple core > feature. > So my solr.xml is like : > > >

Re: Index Comma Separated numbers

I forgot to put formatStyle="number" on the field. It works now. Thanks!! --- On Fri, 6/5/09, Jianbin Dai wrote: > From: Jianbin Dai > Subject: Re: Index Comma Separated numbers > To: solr-user@lucene.apache.org, noble.p...@gmail.com > Date: Friday, June 5, 2009, 12:3

Re: Index Comma Separated numbers

Hi, Yes, I put it in data-config.xml, like following wrote: > From: Noble Paul നോബിള്‍ नोब्ळ् > Subject: Re: Index Comma Separated numbers > To: solr-user@lucene.apache.org > Date: Thursday, June 4, 2009, 9:24 PM >

Re: Index Comma Separated numbers

did you try the NumberFormatTransformer ? On Fri, Jun 5, 2009 at 12:09 AM, Jianbin Dai wrote: > > Hi, One of the fields to be indexed is price which is comma separated, e.g., > 12,034.00.  How can I indexed it as a number? > I am using DIH to pull the data. Thanks. > > > > > -- -

Re: index time boosting on multivalued fields

What are you really trying to accomplish here? Because index time boostingis a way of saying "I care about matches in this field of this document X times more than other documents" whereas search time boosting expresses "elevate the relevance of any document where this term matches" >From your ex

Re: index version command

; > > > - Original Message > > From: nk 11 > > To: solr-user@lucene.apache.org > > Sent: Thursday, May 28, 2009 2:54:08 PM > > Subject: Re: index version command > > > > Thanks. So I should parse the html result? I was thinking about something > &g

Re: index version command

View the source of that page, it should be all XML, so you can easily parse it. Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch - Original Message > From: nk 11 > To: solr-user@lucene.apache.org > Sent: Thursday, May 28, 2009 2:54:08 PM > Subjec

Re: index version command

Thanks. So I should parse the html result? I was thinking about something more "machine readable". On Thu, May 28, 2009 at 9:01 PM, Otis Gospodnetic < otis_gospodne...@yahoo.com> wrote: > > Hello, > > You can see the version of the index in the Solr Admin page. > > Otis > -- > Sematext -- http://

Re: index version command

Hello, You can see the version of the index in the Solr Admin page. Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch - Original Message > From: nk 11 > To: solr-user@lucene.apache.org > Sent: Thursday, May 28, 2009 10:29:10 AM > Subject: index version command > >

Re: Index replication without HTTP

If you are running on Unix/Linux, you should be able to use the scripts-based replication with some minor modification. You will need to change the scripts where it try to use HTTP to trigger a commit in Solr. Bill On Wed, May 27, 2009 at 5:36 AM, Ashish P wrote: > > Hi, > I have two instances

Re: Index replication without HTTP

On Wed, May 27, 2009 at 3:06 PM, Ashish P wrote: > > Hi, > I have two instances of embedded server (no http) running on a network with > two separate indexes.. > I want to replicate changes from one index to other. > Is there any way?? > EmbeddedSolrServer is meant for small scale usage -- like

Re: Index size concerns

Thank you Otis, I will for sure check on this wa salaam, Muhammed Sameer --- On Tue, 5/26/09, Otis Gospodnetic wrote: > From: Otis Gospodnetic > Subject: Re: Index size concerns > To: solr-user@lucene.apache.org > Date: Tuesday, May 26, 2009, 1:01 PM > > Muhammed, >

Re: Index size concerns

: solr-user@lucene.apache.org > Sent: Monday, May 25, 2009 1:22:15 PM > Subject: Re: Index size concerns > > > Salaam, > > Sorry for this here is the big picture > > Actually we use solr to index all the mails that come to us so that we can > allow > for faster loo

Re: Index size concerns

conveying the problem What I wanted to know is that is this index size normal ? Regards, Muhammed Sameer --- On Mon, 5/25/09, Shalin Shekhar Mangar wrote: > From: Shalin Shekhar Mangar > Subject: Re: Index size concerns > To: solr-user@lucene.apache.org > Date: Monday, May 25, 2009, 11:19

Re: Index size concerns

On Mon, May 25, 2009 at 3:53 PM, Muhammed Sameer wrote: > > We are using apache-solr to index our files for faster searches, all things > happen without a problem, my only concern is the size of the cache. > > It seems that the trend is that the if I cache 1 GB of files the index goes > to 800MB i

<    3   4   5   6   7   8   9   10   >