Re: Issue with FacetFields.addFields() throwing ArrayIndexOutOfBoundsException

Can you open an issue and attach the test there? On Jan 18, 2014 12:41 AM, "Matthew Petersen" wrote: > I do have a test that will reproduce. I'm not adding categories with very > deep hierarchies, I'm adding 129 category paths per document (all docs have > paths with same label) with each path h

Re: Issue with FacetFields.addFields() throwing ArrayIndexOutOfBoundsException

I do have a test that will reproduce. I'm not adding categories with very deep hierarchies, I'm adding 129 category paths per document (all docs have paths with same label) with each path having one value. All of the values are completely random and likely unique. It's basically a worst case tes

Re: Issue with FacetFields.addFields() throwing ArrayIndexOutOfBoundsException

Do you have a test which reproduces the error? Are you adding categories with very deep hierarchies? Shai On Fri, Jan 17, 2014 at 11:59 PM, Matthew Petersen wrote: > I've confirmed that using the LruTaxonomyWriterCache solves the issue for > me. It would appear there is in fact a bug in the Cl

Serializing RAMDirectory in 4.6.0

Hi all, In Lucene 3.x the RAMDirectory was Serializable. In 4.x not any more... what's the best/most performant/easies way to serialize the RAMDir in 4.6.0? TIA -- View this message in context: http://lucene.472066.n3.nabble.com/Serializing-RAMDirectory-in-4-6-0-tp4111999.html Sent from the

Re: Issue with FacetFields.addFields() throwing ArrayIndexOutOfBoundsException

I've confirmed that using the LruTaxonomyWriterCache solves the issue for me. It would appear there is in fact a bug in the Cl20TaxonomyWriterCache or I am using it incorrectly (I use it as default, no customization). On Fri, Jan 17, 2014 at 9:29 AM, Matthew Petersen wrote: > I'm sure. I had

Re: Sample Data to Test Lucene

Hi, yes, Lucene is not for OCR. We are using another library for OCR. But we need to get the some source for Lucene. Thanks for the link, I'll take a look at them. Bye, Deniz On Thu, Jan 16, 2014 at 10:05 PM, Allison, Timothy B. wrote: > To confirm, Lucene does not perform OCR. (If you are l

FW: [Jts-topo-suite-user] Persistent STR tree

FYI for those with spatial interests… From: , "Smiley, David W." mailto:dsmi...@mitre.org>> Date: Friday, January 17, 2014 at 11:53 AM To: Demeter Sztanko mailto:szta...@gmail.com>> Cc: "jts-topo-suite-u...@lists.sourceforge.net" mailto:jts-topo

Re: Issue with FacetFields.addFields() throwing ArrayIndexOutOfBoundsException

I'm sure. I had seen that issue and it looked similar but the stack trace is slightly different. I've found that if I replace the Cl2oTaxonomyWriterCache with the LruTaxonomyWriterCache the problem seems to go away. I'm working right now on running a test that will prove this but it takes a whil

Removing/Adding term to one field by docId

Hey! Lucene's API have the ability to change a document, removes and adds the document. I have the need to add/remove a term by docId/field. There is the possibility to perform the link between a term with a field and its existing document? (field -> terms -> term -> DocIds) writer.removeTerm (d

Removing/Adding term to one field by docId

Hey! Lucene's API have the ability to change a document, removes and adds the document. I have the need to add/remove a term by docId/field. There is the possibility to perform the link between a term with a field and its existing document? (field -> terms -> term -> DocIds) writer.removeTerm (d

Re: Presence of uncommitted changes

You might want to look at the soft/hard commit options for insuring data integrity .vs. latency. Here's a blog on this topic at the Solr level, but all the Solr stuff is realized at the Lucene level eventually, so http://searchhub.org/2013/08/23/understanding-transaction-logs-softcommit-and-co

Re: Issue with FacetFields.addFields() throwing ArrayIndexOutOfBoundsException

Are you sure you're using 4.4? Because ... this looks like https://issues.apache.org/jira/browse/LUCENE-5048 but that was supposedly fixed in 4.4. Mike McCandless http://blog.mikemccandless.com On Thu, Jan 16, 2014 at 5:33 PM, Matthew Petersen wrote: > I’m having an issue with an index when a

Re: Presence of uncommitted changes

On Fri, Jan 17, 2014 at 7:42 AM, Mindaugas Žakšauskas wrote: > On Fri, Jan 17, 2014 at 12:13 PM, Michael McCandless >> Backing up, what is your app doing, that it so strongly relies on >> knowing whether commit() would do anything? Usually, commit is >> something you call rarely, for "safety" pur

Re: Presence of uncommitted changes

On Fri, Jan 17, 2014 at 12:13 PM, Michael McCandless > Backing up, what is your app doing, that it so strongly relies on > knowing whether commit() would do anything? Usually, commit is > something you call rarely, for "safety" purposes to ensure if the > world comes crashing down, you'll have a k

Re: Presence of uncommitted changes

On Fri, Jan 17, 2014 at 4:59 AM, Mindaugas Žakšauskas wrote: > Hi, > >>> 1 indexWriter.deleteDocuments(query); // same for terms arg >>> 2 if (indexWriter.hasUncommittedChanges()) { >>> 3 indexWriter.commit(); >>> 4 } >> >> hasUncommittedChanges will return true if you deleted (by Term or >

RE: FieldType.tokenized not the same after query

Uwe, Thanks for the response. This is what I expected, and it's unfortunate (for us). Our software puts an abstraction layer above Lucene (for historical reasons), and expects to be able to pull the same "type" of term (here's the abstraction) from the index that it puts in. It doesn't appear a

Re: Presence of uncommitted changes

Hi, >> 1 indexWriter.deleteDocuments(query); // same for terms arg >> 2 if (indexWriter.hasUncommittedChanges()) { >> 3 indexWriter.commit(); >> 4 } > > hasUncommittedChanges will return true if you deleted (by Term or > Query), even if that Term or Query matches no documents. Mhm, this is

RE: FieldType.tokenized not the same after query

Hi, The indexing settings of FieldTypes are not available in the index. The FieldType information is only used during indexing. IndexReader.document() only returns stored fields, nothing more. This is one reason why Lucene 5.x (currently trunk), no longer shares the same "Document" / "Field" A