[jira] Created: (LUCENE-1945) Make all classes that have a close() methods instanceof Closeable (Java 1.5)
Make all classes that have a close() methods instanceof Closeable (Java 1.5) Key: LUCENE-1945 URL: https://issues.apache.org/jira/browse/LUCENE-1945 Project: Lucene - Java Issue Type: Improvement Affects Versions: 2.9 Reporter: Uwe Schindler Priority: Trivial Fix For: 3.0 This should be simple. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Created: (LUCENE-1946) Remove deprecated TokenStream API
Remove deprecated TokenStream API - Key: LUCENE-1946 URL: https://issues.apache.org/jira/browse/LUCENE-1946 Project: Lucene - Java Issue Type: Task Components: Analysis, contrib/analyzers Reporter: Uwe Schindler Assignee: Uwe Schindler Fix For: 3.0 I looked into clover analysis: It seems to be no longer used since I removed the tests yesterday - I am happy! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1558) Make IndexReader/Searcher ctors readOnly=true by default
[ https://issues.apache.org/jira/browse/LUCENE-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12762000#action_12762000 ] Uwe Schindler commented on LUCENE-1558: --- We have deprecated all these methods and I removed them yesterday. Do you want to put them back again? Make IndexReader/Searcher ctors readOnly=true by default Key: LUCENE-1558 URL: https://issues.apache.org/jira/browse/LUCENE-1558 Project: Lucene - Java Issue Type: Improvement Affects Versions: 2.4.1 Reporter: Michael McCandless Assignee: Michael McCandless Fix For: 3.0 Another change the defaults in 3.0. Right now you get a read/write reader from IndexReader.open and new IndexSearcher(...), and reserving the right to write causes thread contention (on isDeleted). In 3.0 let's make readOnly reader the default, but still allow opening a read/write IndexReader. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Updated: (LUCENE-1946) Remove deprecated TokenStream API
[ https://issues.apache.org/jira/browse/LUCENE-1946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-1946: -- Attachment: LUCENE-1946.patch Short and simple patch for Lucene core. The tests were modified yesterday to no longer call deprecated TS methods and no longer use setOnlyUseNewAPI() Remove deprecated TokenStream API - Key: LUCENE-1946 URL: https://issues.apache.org/jira/browse/LUCENE-1946 Project: Lucene - Java Issue Type: Task Components: Analysis, contrib/analyzers Reporter: Uwe Schindler Assignee: Uwe Schindler Fix For: 3.0 Attachments: LUCENE-1946.patch I looked into clover analysis: It seems to be no longer used since I removed the tests yesterday - I am happy! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
Re: Lucene 2.9 and deprecated IR.open() methods
On 10/4/09 3:31 AM, Mark Miller wrote: Ted Dunning wrote: The builder pattern and the config argument to a factory both have the advantage that you can limit changes after creating an object. Some things are just bad to change in mid-stream. The config argument is nice in that you can pass it around to different stake holders, but the builder can be used a bit like that as well. Yeah that argument has been made. But I've *never* seen it as an issue. Just seems like a solution looking for a problem. I can see how it's cleaner, not missing that point. But still doesn't make me like it much. Yeah personally this wasn't a problem for me either. I do like the cleanliness though. Also, I'd very much prefer a config object over multiple constructors (with the need to deprecate/add with every change), as I proposed originally in this thread. I still don't see an advantage of the builder pattern over the config object + factory pattern - and I'm not even sure if we really need a factory; IMO passing a config object into a single constructor would be sufficient for IW. Michael - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
RE: Lucene 2.9 and deprecated IR.open() methods
The builder pattern and the config argument to a factory both have the advantage that you can limit changes after creating an object. Some things are just bad to change in mid-stream. The config argument is nice in that you can pass it around to different stake holders, but the builder can be used a bit like that as well. Yeah that argument has been made. But I've *never* seen it as an issue. Just seems like a solution looking for a problem. I can see how it's cleaner, not missing that point. But still doesn't make me like it much. Yeah personally this wasn't a problem for me either. I do like the cleanliness though. Also, I'd very much prefer a config object over multiple constructors (with the need to deprecate/add with every change), as I proposed originally in this thread. I still don't see an advantage of the builder pattern over the config object + factory pattern - and I'm not even sure if we really need a factory; IMO passing a config object into a single constructor would be sufficient for IW. For IR the factory would be ok. In my opinion you could also combine both patterns: - Each setter in the config object returns itself, so you have the builder pattern, but you could also use it in classical setter way (this only works if the builder pattern always returns itself not a new builder object) - The builder factory .build() just delegates to the ctor/static factory in IR/IW and passes itself to it). So you have both possibilities: IndexReader reader = new IndexReader.Config(dir).setReadOnly(true) .setTermInfosIndexDivisor(foo).build(); is equal to: IndexReader.Config config = IndexReader.Config(dir); config.setReadOnly(true); config.setTermInfosIndexDivisor(foo); IndexReader reader = IndexReader.create(config); Uwe - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1558) Make IndexReader/Searcher ctors readOnly=true by default
[ https://issues.apache.org/jira/browse/LUCENE-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12762009#action_12762009 ] Michael McCandless commented on LUCENE-1558: bq. Do you want to put them back again? I think we should? Ie, readOnly=true is the natural default for creating an IndexReader? Seems silly to force people to specify true/false when they create an IndexReader. But maybe wait until we reach closure on the config/builder discussion on java-dev? Make IndexReader/Searcher ctors readOnly=true by default Key: LUCENE-1558 URL: https://issues.apache.org/jira/browse/LUCENE-1558 Project: Lucene - Java Issue Type: Improvement Affects Versions: 2.4.1 Reporter: Michael McCandless Assignee: Michael McCandless Fix For: 3.0 Another change the defaults in 3.0. Right now you get a read/write reader from IndexReader.open and new IndexSearcher(...), and reserving the right to write causes thread contention (on isDeleted). In 3.0 let's make readOnly reader the default, but still allow opening a read/write IndexReader. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1257) Port to Java5
[ https://issues.apache.org/jira/browse/LUCENE-1257?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12762012#action_12762012 ] Paul Elschot commented on LUCENE-1257: -- Uwe, thanks for adding the changes.txt entry and committing the contrib/surround StringBuffer to StringBuilder patch. Port to Java5 - Key: LUCENE-1257 URL: https://issues.apache.org/jira/browse/LUCENE-1257 Project: Lucene - Java Issue Type: Improvement Components: Analysis, Examples, Index, Other, Query/Scoring, QueryParser, Search, Store, Term Vectors Affects Versions: 2.3.1 Reporter: Cédric Champeau Assignee: Uwe Schindler Priority: Minor Fix For: 3.0 Attachments: instantiated_fieldable.patch, java5.patch, LUCENE-1257-Document.patch, LUCENE-1257-StringBuffer.patch, LUCENE-1257-StringBuffer.patch, LUCENE-1257-StringBuffer.patch, LUCENE-1257_messages.patch, lucene1257surround1.patch, lucene1257surround1.patch, shinglematrixfilter_generified.patch For my needs I've updated Lucene so that it uses Java 5 constructs. I know Java 5 migration had been planned for 2.1 someday in the past, but don't know when it is planned now. This patch against the trunk includes : - most obvious generics usage (there are tons of usages of sets, ... Those which are commonly used have been generified) - PriorityQueue generification - replacement of indexed for loops with for each constructs - removal of unnececessary unboxing The code is to my opinion much more readable with those features (you actually *know* what is stored in collections reading the code, without the need to lookup for field definitions everytime) and it simplifies many algorithms. Note that this patch also includes an interface for the Query class. This has been done for my company's needs for building custom Query classes which add some behaviour to the base Lucene queries. It prevents multiple unnnecessary casts. I know this introduction is not wanted by the team, but it really makes our developments easier to maintain. If you don't want to use this, replace all /Queriable/ calls with standard /Query/. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1558) Make IndexReader/Searcher ctors readOnly=true by default
[ https://issues.apache.org/jira/browse/LUCENE-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12762011#action_12762011 ] Uwe Schindler commented on LUCENE-1558: --- Kr, I rewrote all tests to add this parameter :( Make IndexReader/Searcher ctors readOnly=true by default Key: LUCENE-1558 URL: https://issues.apache.org/jira/browse/LUCENE-1558 Project: Lucene - Java Issue Type: Improvement Affects Versions: 2.4.1 Reporter: Michael McCandless Assignee: Michael McCandless Fix For: 3.0 Another change the defaults in 3.0. Right now you get a read/write reader from IndexReader.open and new IndexSearcher(...), and reserving the right to write causes thread contention (on isDeleted). In 3.0 let's make readOnly reader the default, but still allow opening a read/write IndexReader. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
Re: Lucene 2.9 and deprecated IR.open() methods
I don't think we should do both. Suddenly, all code snippets (in javadocs, tutorials, email we all send, etc.) can be one pattern or the other, with each of us choosing based on our preference. Or, mixed. I think this just causes confusion. It'd suddenly become alot like differences of opinion on which whitespace style is best. I'd rather have one clear syntax, and at this point I'd prefer to stick with the classical setter approach, ie a standalone config object. But there are two other (more important than pure syntax!) questions being debated here: 1 Do we prevent config settings from changing after creating an IW/IR? 2 Do we use factory or ctor to create IW/IR? On #1, we are technically taking something away. Are we sure no users find the freedom to change IW settings mid-stream (ramBufferSizeMB, mergeFactor) important? For example, infoStream should remain an IW setter. Also, MergePolicy now requires IW instance on construction, so we'd need to rework that. On #2, I agree with Michael: until we see a clear reason to hide IW's concrete impl., we may as well stick with the one impl we have now. Design for today. Mike On Sun, Oct 4, 2009 at 5:33 AM, Uwe Schindler u...@thetaphi.de wrote: The builder pattern and the config argument to a factory both have the advantage that you can limit changes after creating an object. Some things are just bad to change in mid-stream. The config argument is nice in that you can pass it around to different stake holders, but the builder can be used a bit like that as well. Yeah that argument has been made. But I've *never* seen it as an issue. Just seems like a solution looking for a problem. I can see how it's cleaner, not missing that point. But still doesn't make me like it much. Yeah personally this wasn't a problem for me either. I do like the cleanliness though. Also, I'd very much prefer a config object over multiple constructors (with the need to deprecate/add with every change), as I proposed originally in this thread. I still don't see an advantage of the builder pattern over the config object + factory pattern - and I'm not even sure if we really need a factory; IMO passing a config object into a single constructor would be sufficient for IW. For IR the factory would be ok. In my opinion you could also combine both patterns: - Each setter in the config object returns itself, so you have the builder pattern, but you could also use it in classical setter way (this only works if the builder pattern always returns itself not a new builder object) - The builder factory .build() just delegates to the ctor/static factory in IR/IW and passes itself to it). So you have both possibilities: IndexReader reader = new IndexReader.Config(dir).setReadOnly(true) .setTermInfosIndexDivisor(foo).build(); is equal to: IndexReader.Config config = IndexReader.Config(dir); config.setReadOnly(true); config.setTermInfosIndexDivisor(foo); IndexReader reader = IndexReader.create(config); Uwe - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-1558) Make IndexReader/Searcher ctors readOnly=true by default
[ https://issues.apache.org/jira/browse/LUCENE-1558?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12762014#action_12762014 ] Michael McCandless commented on LUCENE-1558: But, the tests can keep that change (being explicit about read-only). Make IndexReader/Searcher ctors readOnly=true by default Key: LUCENE-1558 URL: https://issues.apache.org/jira/browse/LUCENE-1558 Project: Lucene - Java Issue Type: Improvement Affects Versions: 2.4.1 Reporter: Michael McCandless Assignee: Michael McCandless Fix For: 3.0 Another change the defaults in 3.0. Right now you get a read/write reader from IndexReader.open and new IndexSearcher(...), and reserving the right to write causes thread contention (on isDeleted). In 3.0 let's make readOnly reader the default, but still allow opening a read/write IndexReader. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Updated: (LUCENE-1946) Remove deprecated TokenStream API
[ https://issues.apache.org/jira/browse/LUCENE-1946?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-1946: -- Attachment: LUCENE-1946.patch Some more changes and additional tests (removed by the backwards-testcase removal). It now also fixes contrib/analyzers. There are still some problems in contrib like tests or old-style consumers. Remove deprecated TokenStream API - Key: LUCENE-1946 URL: https://issues.apache.org/jira/browse/LUCENE-1946 Project: Lucene - Java Issue Type: Task Components: Analysis, contrib/analyzers Reporter: Uwe Schindler Assignee: Uwe Schindler Fix For: 3.0 Attachments: LUCENE-1946.patch, LUCENE-1946.patch I looked into clover analysis: It seems to be no longer used since I removed the tests yesterday - I am happy! -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
Re: Lucene 2.9 and deprecated IR.open() methods
On Sun, Oct 4, 2009 at 5:53 AM, Michael McCandless luc...@mikemccandless.com wrote: 1 Do we prevent config settings from changing after creating an IW/IR? 2 Do we use factory or ctor to create IW/IR? On #1, we are technically taking something away. Are we sure no users find the freedom to change IW settings mid-stream (ramBufferSizeMB, mergeFactor) important? Some of these are important I think - esp changing merge factor or the max segment size. Seems like everything that should be fixed at construction time (simple params at least) can be passed in the config object, and everything else can remain setters on the IndexWriter. Of course things like max segment size have been factored out into the merge policies... but you get the idea. -Yonik http://www.lucidimagination.com - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Issue Comment Edited: (LUCENE-1910) Extension to MoreLikeThis to use tag information
[ https://issues.apache.org/jira/browse/LUCENE-1910?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12761997#action_12761997 ] Thomas D'Silva edited comment on LUCENE-1910 at 10/4/09 10:21 AM: -- Mark, I refactored the class to include more descriptive variable names. I also modified the code so that while calculating information gain only terms belonging to documents that have been tagged with the given tag and used (and not all the terms in the index). I tested this class on a test index containing one million documents. The documents were tagged with five tags (tag_0...tag_4). tag_0 was assigned to approximately 10% of the documents, tag_1 to 20% and so on. tag name, number of documents, time in ms tag_0, 10134, 137314 tag_1, 19996, 219527 tag_2, 30010, 315336 tag_3, 39907, 413615 tag_4, 50148, 507350 The time taken to generate the query for a tag depends on the number of documents in the index containing the tag and scales linearly with the number of documents. The top document terms for a given are cached in a hashmap once they have been generated in order to speed up subsequent lookups. Thanks, Thomas was (Author: twdsi...@gmail.com): I refactored the class to include more descriptive variable names. I also modified the code so that while calculating information gain only terms belonging to documents that have been tagged with the given tag and used (and not all the terms in the index). I tested this class on a test index containing one million documents. The documents were tagged with five tags (tag_0...tag_4). tag_0 was assigned to approximately 10% of the documents, tag_1 to 20% and so on. tag name, number of documents, time in ms tag_0, 10134, 137314 tag_1, 19996, 219527 tag_2, 30010, 315336 tag_3, 39907, 413615 tag_4, 50148, 507350 The time taken to generate the query for a tag depends on the number of documents in the index containing the tag and scales linearly with the number of documents. The top document terms for a given are cached in a hashmap once they have been generated in order to speed up subsequent lookups. Extension to MoreLikeThis to use tag information Key: LUCENE-1910 URL: https://issues.apache.org/jira/browse/LUCENE-1910 Project: Lucene - Java Issue Type: New Feature Components: contrib/* Reporter: Thomas D'Silva Priority: Minor Attachments: LUCENE-1910.patch, LUCENE-1910.patch I would like to contribute a class based on the MoreLikeThis class in contrib/queries that generates a query based on the tags associated with a document. The class assumes that documents are tagged with a set of tags (which are stored in the index in a seperate Field). The class determines the top document terms associated with a given tag using the information gain metric. While generating a MoreLikeThis query for a document the tags associated with document are used to determine the terms in the query. This class is useful for finding similar documents to a document that does not have many relevant terms but was tagged. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Updated: (LUCENE-1910) Extension to MoreLikeThis to use tag information
[ https://issues.apache.org/jira/browse/LUCENE-1910?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Thomas D'Silva updated LUCENE-1910: --- Attachment: (was: LUCENE-1910.patch) Extension to MoreLikeThis to use tag information Key: LUCENE-1910 URL: https://issues.apache.org/jira/browse/LUCENE-1910 Project: Lucene - Java Issue Type: New Feature Components: contrib/* Reporter: Thomas D'Silva Priority: Minor Attachments: LUCENE-1910.patch I would like to contribute a class based on the MoreLikeThis class in contrib/queries that generates a query based on the tags associated with a document. The class assumes that documents are tagged with a set of tags (which are stored in the index in a seperate Field). The class determines the top document terms associated with a given tag using the information gain metric. While generating a MoreLikeThis query for a document the tags associated with document are used to determine the terms in the query. This class is useful for finding similar documents to a document that does not have many relevant terms but was tagged. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Updated: (LUCENE-1929) Highlighter doesn't support NumericRangeQuery or deprecated RangeQuery
[ https://issues.apache.org/jira/browse/LUCENE-1929?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated LUCENE-1929: Attachment: LUCENE-1929.patch The 2.9.1 fix Highlighter doesn't support NumericRangeQuery or deprecated RangeQuery -- Key: LUCENE-1929 URL: https://issues.apache.org/jira/browse/LUCENE-1929 Project: Lucene - Java Issue Type: Bug Components: contrib/highlighter Affects Versions: 2.9 Reporter: Mark Miller Assignee: Mark Miller Attachments: LUCENE-1929.patch Sucks. Will throw a NullPointer exception. Only NumericRangeQuery will throw the exception. RangeQuery just won't highlight. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online. - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
Re: Lucene 2.9 and deprecated IR.open() methods
As I stated in my last email, there's zero difference between settings+static factory and builder except for syntax. Cannot understand what Mark, Mike are arguing about. Right now I offer to do two things, in any possible way - eradicate as much broken/spahetti-like runtime state change from IW and friends as possible, and kill setting methods that delegate to IW components (eg MergePolicy), as they are redundant and suddenly break if you supply a non-default component instance. On Sun, Oct 4, 2009 at 17:55, Yonik Seeley ysee...@gmail.com wrote: On Sun, Oct 4, 2009 at 5:53 AM, Michael McCandless luc...@mikemccandless.com wrote: 1 Do we prevent config settings from changing after creating an IW/IR? 2 Do we use factory or ctor to create IW/IR? On #1, we are technically taking something away. Are we sure no users find the freedom to change IW settings mid-stream (ramBufferSizeMB, mergeFactor) important? Some of these are important I think - esp changing merge factor or the max segment size. The question is - whether anybody's going to change mergefactor/maxsegment size often enough he can't recreate IW without dire performance penalties? Seems like everything that should be fixed at construction time (simple params at least) can be passed in the config object, and everything else can remain setters on the IndexWriter. Of course things like max segment size have been factored out into the merge policies... but you get the idea. -Yonik http://www.lucidimagination.com - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org -- Kirill Zakharenko/Кирилл Захаренко (ear...@gmail.com) Home / Mobile: +7 (495) 683-567-4 / +7 (903) 5-888-423 ICQ: 104465785 - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
Re: Lucene 2.9 and deprecated IR.open() methods
Earwin Burrfoot wrote: As I stated in my last email, there's zero difference between settings+static factory and builder except for syntax. Cannot understand what Mark, Mike are arguing about. Sounds like we are arguing that we don't like the syntax then... kill setting methods that delegate to IW components (eg MergePolicy), as they are redundant and suddenly break if you supply a non-default component instance. I do agree that this is something that should be addressed. On Sun, Oct 4, 2009 at 17:55, Yonik Seeley ysee...@gmail.com wrote: On Sun, Oct 4, 2009 at 5:53 AM, Michael McCandless luc...@mikemccandless.com wrote: 1 Do we prevent config settings from changing after creating an IW/IR? 2 Do we use factory or ctor to create IW/IR? On #1, we are technically taking something away. Are we sure no users find the freedom to change IW settings mid-stream (ramBufferSizeMB, mergeFactor) important? Some of these are important I think - esp changing merge factor or the max segment size. The question is - whether anybody's going to change mergefactor/maxsegment size often enough he can't recreate IW without dire performance penalties? Seems like everything that should be fixed at construction time (simple params at least) can be passed in the config object, and everything else can remain setters on the IndexWriter. Of course things like max segment size have been factored out into the merge policies... but you get the idea. -Yonik http://www.lucidimagination.com - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org -- - Mark http://www.lucidimagination.com - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
Re: Lucene 2.9 and deprecated IR.open() methods
On Sun, Oct 04, 2009 at 03:04:13PM -0400, Mark Miller wrote:
Earwin Burrfoot wrote:
As I stated in my last email, there's zero difference between
settings+static factory and builder except for syntax. Cannot
understand what Mark, Mike are arguing about.
Sounds like we are arguing that we don't like the syntax then...
So, implement the static factory methods as wrappers around the builder
method.
public static IndexWriter open(Directory dir, Analyzer analyzer) {
return open(new IndexManager(dir), dir, analyzer)
}
public static IndexWriter open(IndexManager manager, Directory dir,
Analyzer analyzer) {
return arch.buildIndexWriter(new Architecture(), manager, dir, analyzer);
}
public static IndexWriter open(Architecture arch, IndexManager manager,
Directory dir, Analyzer analyzer) {
return arch.buildIndexWriter(manager, dir, analyzer);
}
IMO, it's important not to force first-time users to grok builder classes in
order to perform basic indexing or searching.
Marvin Humphrey
-
To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: java-dev-h...@lucene.apache.org
Re: Lucene 2.9 and deprecated IR.open() methods
On Sun, Oct 04, 2009 at 05:53:14AM -0400, Michael McCandless wrote: 1 Do we prevent config settings from changing after creating an IW/IR? Any settings conveyed via a settings object ought to be final if you want pluggable index components. Otherwise, you need some nightmarish notification system to propagate settings down into your subcomponents, which may or may not be prepared to handle the value modifications. Marvin Humphrey - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
