JavaDoc Bug
I suppose I should open a bug report on this... but I'm feeling lazy.. sorry. The javadoc page http://lucene.apache.org/java/docs/api/org/apache/lucene/queryParser/QueryParser.html Has a link it it to the "test cases" in the class description. This link points to http://lucene.apache.org/java/src/test/org/apache/lucene/queryParser/TestQueryParser.java Which gives a 404 error. Dan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: limit return results
haipeng du wrote: That is just my concern because my big number of documents I will have(at least 4 million documents). 4 million documents is nothing - many people routinely search on much larger Lucene Indexes than that. Test first. Then find and fix your bottlenecks and/or high memory use items. My hunch is that you will discover that you are wasting time worrying about potential problems that will not occur. You time would be better spent doing some real testing, and working to improve your code from there, as you discover real (rather then potential) problems. Dan -- Daniel Armbrust Biomedical Informatics Mayo Clinic Rochester daniel.armbrust(at)mayo.edu http://informatics.mayo.edu/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: 1.9 RC1
I'd like to see this improvement request implemented - but I'm not sure if 1.9 or 2.0 would be a better place to do it: http://issues.apache.org/jira/browse/LUCENE-301 Short summary - The Constructor for IndexWriter currently will only create an index in a folder if you set the boolean create flag to true. But then, if you want to append to that index, you have to set the create flag to false (otherwise it overwrites) In my use cases, I seldom want to overwrite an index - but I often create new ones, and append to existing ones. Forgetting to switch the boolean flag between the initial create and the append causes data loss. To me, a better, safer API would be to change the parameter named "create" into "clear" - and then change the behavior so that is always creates a new index at the specified location if one doesn't already exist. If clear is false - it would append (same as current behavior) - and if clear is true is would clear first, and then create a new index. So nobody using the API should break. Dan -- Daniel Armbrust Biomedical Informatics Mayo Clinic Rochester daniel.armbrust(at)mayo.edu http://informatics.mayo.edu/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Results (Re: Survey: Lucene and Java 1.4 vs. 1.5)
Robert Engels wrote: People making these arguments against 1.5 sound really ill-informed, or lazy. Neither of which is good for open-source development. Preface - I'm not a lucene developer - just an interested user. I don't know - it seems to me that it is the 1.5 crowd that is making the lazy argument. You are in effect, saying, that the highly skilled developers who would be making lucene contributions are unable or unwilling to write 1.4 java code? Come on... it really not that hard. Which set is being lazy? I'll stop the name calling now, and try to make a better point. I have some applications that I have written in 1.5 - and yes - it is nice. But I also have other applications (that use Lucene) that are written to be 1.4 compatible. And they need to stay that way for quite some time to come. Why? Many reasons. The first - because they implement an official HL7 specification - and the specification says that the implementation needs to support Java 1.4. Also, at my place of employment we have about 40,000 desktop computers that are all centrally managed - down to every point release of every single piece of software. There are multiple applications using java that are installed on these machines. Each application has to be certified and fully tested with a newer version of java before a newer version of java can be installed. As you can imagine, that severely hampers the pace of java updates. We are just getting 1.4 installed on these machines now. When you are managing that many machines in a clinical environment - you have to play it safe. There are no upgrades for an upgrades sake, or for syntactic sugar. There has to be a real problem to even get the process started. I'm sure many other people have similar situations. Also - I don't know much about the Java mobile platform - but I thought I had read before that they are limited to the 1.3 or 1.4 feature set? If this is true, do we really want to remove an entire ecosystem of potential users? Over syntactic sugar? While I'm not completely opposed to the argument that I should just have to stay with the Lucene 2.0.x release with applications that need to run in 1.4 environments - Lucene is an integral part of that code. If performance improvements are made to the core, I want those in my code. If bugs are found and fixed - I want those fixes too. As a matter of fact - until the 2.0 release, I was using a build from the trunk because of a bug that I found in Lucene, (and someone else was gracious enough to fix for me). Lucene is a low level library that is used to build many great applications. If you make the jump to 1.5 today - you are going to be leaving people behind. And judging by the poll, you are going to be leaving a fairly significant number of people behind. Lucene has great policy on not breaking backwards compatibility in their API - why should this be looked at any differently? > Rather than having the 1.5 developers having to waste their time > "thinking" in 1.4 when their work is predominately being performed > using 1.5 features/compilers/tools. I don't think that the caliber of developers that are working on the Lucene core are going to be slowed down any by using 1.4 syntax over 1.5. (It actually takes longer to type in all of those generics :) All of my tools - Eclipse and Java 1.5 - have a check box that will cause them to generate 1.4 compatible code. Its really _not_ a big deal to write 1.4 code even if you are used to 1.5. This particular argument just isn't compelling to me. My personal opinion for the path that Lucene should take: Core bugs fixes must be 1.4 compatible. Core improvements must be 1.4 compatible. Contrib / sandbox can be 1.5 or 1.6. Of course, at some point - Lucene Core does need to advance. But I don't just don't feel that syntactic sugar in 1.5 is enough of a reason to break backwards compatibility. I haven't followed 1.6 - I don't know what the new features are there. Assuming that there are great new features in 1.6 - that would improve the lucene core if they were used - I think that that is when this issue gets revisited. This isn't the type of question that should be decided by a poll. This should be decided by thoughtfully looking at the consequences of each choice. For me - the negative consequences of choosing 1.5 - leaving behind a lot of users - is much worse than the negative consequences of staying at 1.4 - making a couple dozen highly skilled developers check an extra box in their lucene development environments? If any developers have actually read this far (sorry - it got kind of long) - thanks again for all of your great work - Lucene is a great tool - and a great community. Dan -- Daniel Armbrust Biomedical Informatics Mayo Clinic Rochester daniel.armbrust(at)mayo.edu http://informatics.mayo.edu/ ---
[jira] Commented: (LUCENE-301) Index Writer constructor flags unclear - and annoying in certain cases
[ http://issues.apache.org/jira/browse/LUCENE-301?page=comments#action_12330502 ] Dan Armbrust commented on LUCENE-301: - Could this be addresses or WONT FIXED before the 1.9 release? > Index Writer constructor flags unclear - and annoying in certain cases > -- > > Key: LUCENE-301 > URL: http://issues.apache.org/jira/browse/LUCENE-301 > Project: Lucene - Java > Type: Improvement > Components: Index > Versions: 1.4 > Environment: Operating System: other > Platform: Other > Reporter: Dan Armbrust > Assignee: Lucene Developers > Priority: Minor > > Wouldn't it make more sense if the constructor for the IndexWriter always > created an index if it doesn't exist - and the boolean parameter should be > "clear" (instead of "create") > So instead of this (from javadoc): > IndexWriter > public IndexWriter(Directory d, >Analyzer a, >boolean create) > throws IOException > Constructs an IndexWriter for the index in d. Text will be analyzed with > a. > If create is true, then a new, empty index will be created in d, replacing the > index already there, if any. > Parameters: > d - the index directory > a - the analyzer to use > create - true to create the index or overwrite the existing one; false to > append to the existing index > Throws: > IOException - if the directory cannot be read/written to, or if it does > not > exist, and create is false > We would have this: > IndexWriter > public IndexWriter(Directory d, >Analyzer a, >boolean clear) > throws IOException > Constructs an IndexWriter for the index in d. Text will be analyzed with > a. > If clear is true, and a index exists at location d, then it will be erased, > and > a new, empty index will be created in d. > Parameters: > d - the index directory > a - the analyzer to use > clear - true to overwrite the existing one; false to append to the > existing > index > Throws: > IOException - if the directory cannot be read/written to, or if it does > not > exist. > Its current behavior is kind of annoying, because I have an app that should > never clear an existing index, it should always append. So I want create set > to > false. But when I am starting a brand new index, then I have to change the > create flag to keep it from throwing an exception... I guess for now I will > have to write code to check if a index actually has content yet, and if it > doesn't, change the flag on the fly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-301) Index Writer constructor flags unclear - and annoying in certain cases
[ http://issues.apache.org/jira/browse/LUCENE-301?page=comments#action_12367239 ] Dan Armbrust commented on LUCENE-301: - I'm perfectly happy with either new constructor approach - as long as there is a better constructor than what is currently available for my (and I suspect many other folks) "normal" use case of these constructors. It doesn't really matter to me if the current one stays or gets deprecated. If it was going to be deprecated, it seems like 1.9 would be a good place to do it. > Index Writer constructor flags unclear - and annoying in certain cases > -- > > Key: LUCENE-301 > URL: http://issues.apache.org/jira/browse/LUCENE-301 > Project: Lucene - Java > Type: Improvement > Components: Index > Versions: 1.4 > Environment: Operating System: other > Platform: Other > Reporter: Dan Armbrust > Assignee: Lucene Developers > Priority: Minor > > Wouldn't it make more sense if the constructor for the IndexWriter always > created an index if it doesn't exist - and the boolean parameter should be > "clear" (instead of "create") > So instead of this (from javadoc): > IndexWriter > public IndexWriter(Directory d, >Analyzer a, >boolean create) > throws IOException > Constructs an IndexWriter for the index in d. Text will be analyzed with > a. > If create is true, then a new, empty index will be created in d, replacing the > index already there, if any. > Parameters: > d - the index directory > a - the analyzer to use > create - true to create the index or overwrite the existing one; false to > append to the existing index > Throws: > IOException - if the directory cannot be read/written to, or if it does > not > exist, and create is false > We would have this: > IndexWriter > public IndexWriter(Directory d, >Analyzer a, >boolean clear) > throws IOException > Constructs an IndexWriter for the index in d. Text will be analyzed with > a. > If clear is true, and a index exists at location d, then it will be erased, > and > a new, empty index will be created in d. > Parameters: > d - the index directory > a - the analyzer to use > clear - true to overwrite the existing one; false to append to the > existing > index > Throws: > IOException - if the directory cannot be read/written to, or if it does > not > exist. > Its current behavior is kind of annoying, because I have an app that should > never clear an existing index, it should always append. So I want create set > to > false. But when I am starting a brand new index, then I have to change the > create flag to keep it from throwing an exception... I guess for now I will > have to write code to check if a index actually has content yet, and if it > doesn't, change the flag on the fly. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Created: (LUCENE-540) Merging multiple indexes does not maintain document order.
Merging multiple indexes does not maintain document order. -- Key: LUCENE-540 URL: http://issues.apache.org/jira/browse/LUCENE-540 Project: Lucene - Java Type: Bug Versions: 1.9 Environment: Windows XP, Java 1.5.0_05 Fedora Core 3 - 64 bit - Java 1.5.0_06 (64 bit) Lucene 1.9.1 (issue tracker doesn't have a 1.9.1 option) Reporter: Dan Armbrust When I merge multiple indexes into a single, empty index, the document addition order is not being maintained. Self contained test case coming (as soon as I figure out how to attach it) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Updated: (LUCENE-540) Merging multiple indexes does not maintain document order.
[ http://issues.apache.org/jira/browse/LUCENE-540?page=all ] Dan Armbrust updated LUCENE-540: Attachment: LuceneBug.java The attached JUnit test case should demonstrate the problem. See the comments inside of the test case. > Merging multiple indexes does not maintain document order. > -- > > Key: LUCENE-540 > URL: http://issues.apache.org/jira/browse/LUCENE-540 > Project: Lucene - Java > Type: Bug > Versions: 1.9 > Environment: Windows XP, Java 1.5.0_05 > Fedora Core 3 - 64 bit - Java 1.5.0_06 (64 bit) > Lucene 1.9.1 (issue tracker doesn't have a 1.9.1 option) > Reporter: Dan Armbrust > Attachments: LuceneBug.java > > When I merge multiple indexes into a single, empty index, the document > addition order is not being maintained. > Self contained test case coming (as soon as I figure out how to attach it) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-540) Merging multiple indexes does not maintain document order.
[ http://issues.apache.org/jira/browse/LUCENE-540?page=comments#action_12373500 ] Dan Armbrust commented on LUCENE-540: - Fix verified here. Thanks for the rapid repair. > Merging multiple indexes does not maintain document order. > -- > > Key: LUCENE-540 > URL: http://issues.apache.org/jira/browse/LUCENE-540 > Project: Lucene - Java > Type: Bug > Versions: 1.9 > Environment: Windows XP, Java 1.5.0_05 > Fedora Core 3 - 64 bit - Java 1.5.0_06 (64 bit) > Lucene 1.9.1 (issue tracker doesn't have a 1.9.1 option) > Reporter: Dan Armbrust > Assignee: Yonik Seeley > Fix For: 2.0 > Attachments: LuceneBug.java, TestMergeIndexDocOrder.java > > When I merge multiple indexes into a single, empty index, the document > addition order is not being maintained. > Self contained test case coming (as soon as I figure out how to attach it) -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
