RE: back_compat folders in tags when I SVN update
Thanks for the clarification Chris. My key concern was that tags was becoming too crowded as-is, and important data is getting lost in the crowd. Looks like Uwe has a solution per https://issues.apache.org/jira/browse/LUCENE-2193. If this won't do, I like you suggestion of structuring tags per your example below. -- George -Original Message- From: Chris Hostetter [mailto:hossman_luc...@fucit.org] Sent: Wednesday, January 06, 2010 2:21 PM To: java-dev@lucene.apache.org Subject: RE: back_compat folders in tags when I SVN update : I prefer to see tags used for what it is, a place to park an actually : released; it shouldn't be used for testing or its content changed : dynamically. I have no opinion about the rest of this thread (changing the back compat testing to use a specific revision on the previous release branch) but as for this specific comment: it's really a mistake to think of tags as only being for releases. the TTB convetion in svn (trunk, tags, branches) stems from what's considered a best practice when migrating from CVS: trunk corrisponds to MAIN in cvs, the branches directory corrisponds to the list of branching tags in CVS, and the tag directory corrisponds to the list of tags in CVS. there is nothing special about the concept of a CVS/SVN tag that should make it synonymous in peopls minds with a release ... yes we tag every release, but there are lots of other reasons to tag things in both CVS and SVN: release candidates are frequently taged, many other projects tag stable builds from their continuous integration system ... a developer could create an aritrary checkpoint tag to denote when there was a dramatic shift in development in a project in case people wnated to easily find when that shift happened so they could go back and fork a branch at that point if that approach was deemed unsuccessful. bottom line: not a good idea to assume all tags are releases. (that said: the TTB convetion is nothing more then a convention ... there's nothing to stop us from using a more verbose directory hierarchy to isolate release tags in a single place.. ./trunk ./branches/branch_a ./... ./tags ./tags/releases ./tags/releases/2_9_0 ./... ./tags/some_misc_tag ) -Hoss - 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
RE: Lucene Java 2.9.2
Yes, the goal is to be 1-to-1 in sync which is how it always has been and why version number consistency is important. A Lucene.Net assembly, has version number with 4 digits, like so: Lucene.Net 2.9.1.016 -- the last number 016 is used to both signify an internal release, as the port is progressing, and bug fix specific to porting issues. In this case, my question was about porting over only 1 patch from Lucene Java 2.9.2 to Lucene.Net 2.9.1 (i.e.: a patch found in newer version of Lucene Java to an older version of Lucene.Net). If we do so, (which I'm against the idea and over at Lucene.Net we decided not to do so) than this can lead to version confusion if not well documented and possibly introduce behavior differences (based on what the 1 ported patch ends up fixing). Not only this, as you pointed out, what if Lucene Java 2.9.3 comes up, than what? -- George -Original Message- From: Chris Hostetter [mailto:hossman_luc...@fucit.org] Sent: Tuesday, January 05, 2010 3:52 PM To: java-dev@lucene.apache.org Subject: Re: Lucene Java 2.9.2 : https://issues.apache.org/jira/browse/LUCENENET-331). This begs the : question, if Lucene.Net takes just this one patch, than Lucene.Net 2.9.1 is : now 2.9.1.1 (which I personally don't like to see happening as I prefer to : see a 1-to-1 release match). As a general comment on this topic: I would suggest that if the goal of Lucene.Net is to be a 1-to-1 port (which seems like a good goal, but is certainly not mandatory if the Lucene.Net community has other ambitions) then the cleanest thing for users would be to keep the version numbers in sync 1-to-1. it reasises some questions about what to do if a bug is discovered in the *porting*. ie: if after Lucene.Net 2.9.2 is released, it's discovered that there was a glitch, and it doesn't actually match the behavior of Lucene-JAva 2.9.2 what should be done? ... Lucene.Net 2.9.3 and Lucene.Net 2.9.2.1 could all concivably conflict with version numbers Lucene-Java *might* someday release. Having an anotaiton strategy that doesn't extend the dot notation used by Lucene-Java might make sense (ie: Lucene.Net 2.9.2-a -Hoss - 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
RE: back_compat folders in tags when I SVN update
I have http://svn.apache.org/repos/asf/lucene/java/trunk/ and http://svn.apache.org/repos/asf/lucene/java/tags/ checked out. I think having all this back_compat folders, under the tags can be very confusing, especially for someone who looks in tags in search of a released version and finds all the back_compat folders not knowing what they mean (there is more back_compat folders than actually release tags!) If we are using tags for back-compat testing, aren't we overloading the meaning of the tags folder? I prefer to see tags used for what it is, a place to park an actually released; it shouldn't be used for testing or its content changed dynamically. -- George -Original Message- From: Chris Hostetter [mailto:hossman_luc...@fucit.org] Sent: Tuesday, January 05, 2010 3:21 PM To: java-dev@lucene.apache.org Subject: Re: back_compat folders in tags when I SVN update : Why do I see \java\tags\lucene_*_back_compat_tests_2009*\ directories (well : over 100 so far) when I SVN update? Are you saying you have http://svn.apache.org/repos/asf/lucene/java/; checked out in it's entirety? That seems ... problematic. New tags/branches could be created at anytime -- it's even possibly to have Hudson autotag every build if we wanted. Server side these tags are essentially free but if you checkout at the top level you pay the price of local storage on update. I would rethink your checkout strategy. -Hoss - 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
back_compat folders in tags when I SVN update
Hi folks, Why do I see \java\tags\lucene_*_back_compat_tests_2009*\ directories (well over 100 so far) when I SVN update? Thanks. -- George - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Commented: (LUCENE-2076) Add org.apache.lucene.store.FSDirectory.getDirectory()
[ https://issues.apache.org/jira/browse/LUCENE-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12779424#action_12779424 ] George Aroush commented on LUCENE-2076: --- Sure, 3.1 will do. Thanks guys! Add org.apache.lucene.store.FSDirectory.getDirectory() -- Key: LUCENE-2076 URL: https://issues.apache.org/jira/browse/LUCENE-2076 Project: Lucene - Java Issue Type: Wish Components: Store Affects Versions: 3.0 Reporter: George Aroush Assignee: Michael McCandless Priority: Minor Fix For: 3.1 Attachments: FSDirectory.patch On the Apache Lucene.Net side, we have done some clean up with the upcoming 2.9.1 such that we are now depreciating improperly use of parameter type for some public APIs. When we release 3.0, those depreciated code will be removed. One area where we had difficulty with required us to add a new method like so: Lucene.Net.Store.FSDirectory.GetDirectory(). This method does the same thing as Lucene.Net.Store.FSDirectory.GetFile(). This was necessary because we switched over from using System.IO.FileInfo to System.IO.DirectoryInfo. Why? In the .NET world, a file and a directory are two different things. Why did we have to add Lucene.Net.Store.FSDirectory.GetDirectory()? Because we can't change the return type of Lucene.Net.Store.FSDirectory.GetFile() and still remain backward compatible (API wise) to be depreciated with the next release. Why ask for Java Lucene to add org.apache.lucene.store.FSDirectory.getDirectory()? To keep the APIs 1-to-1 in par with Java Lucene and Lucene.Net. -- 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-2076) Add org.apache.lucene.store.FSDirectory.getDirectory()
[ https://issues.apache.org/jira/browse/LUCENE-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] George Aroush updated LUCENE-2076: -- Attachment: FSDirectory.patch Patch attached. Add org.apache.lucene.store.FSDirectory.getDirectory() -- Key: LUCENE-2076 URL: https://issues.apache.org/jira/browse/LUCENE-2076 Project: Lucene - Java Issue Type: Wish Components: Store Affects Versions: 3.0 Reporter: George Aroush Priority: Minor Fix For: 3.0 Attachments: FSDirectory.patch On the Apache Lucene.Net side, we have done some clean up with the upcoming 2.9.1 such that we are now depreciating improperly use of parameter type for some public APIs. When we release 3.0, those depreciated code will be removed. One area where we had difficulty with required us to add a new method like so: Lucene.Net.Store.FSDirectory.GetDirectory(). This method does the same thing as Lucene.Net.Store.FSDirectory.GetFile(). This was necessary because we switched over from using System.IO.FileInfo to System.IO.DirectoryInfo. Why? In the .NET world, a file and a directory are two different things. Why did we have to add Lucene.Net.Store.FSDirectory.GetDirectory()? Because we can't change the return type of Lucene.Net.Store.FSDirectory.GetFile() and still remain backward compatible (API wise) to be depreciated with the next release. Why ask for Java Lucene to add org.apache.lucene.store.FSDirectory.getDirectory()? To keep the APIs 1-to-1 in par with Java Lucene and Lucene.Net. -- 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-2076) Add org.apache.lucene.store.FSDirectory.getDirectory()
[ https://issues.apache.org/jira/browse/LUCENE-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12779101#action_12779101 ] George Aroush commented on LUCENE-2076: --- Mark's response is right on. I'm also fine with adding getDir(), but prefer to see getDirectory(). Uwe, the issue (and I just realized, I didn't clarify this in my original description of this issue) is with the way Java treats java.io.File objects, which can be a file or a directory. As I pointed in the description of this issue, for .NET, a file is managed using System.IO.FileInfo, and a directory is managed using System.IO.DirectoryInfo. Up to Lucene.Net 2.4.0, all ports were done such that we are using System.IO.FileInfo. This meant, internally, and even for public API's, we have to first make sure the object is a directory before using it. With 2.9.1, anywhere we were using System.IO.FileInfo, we are now depreciating them in favor of using System.IO.DirectoryInfo. The one area where we could not do this is for org.apache.lucene.store.FSDirectory.getFile() this is because the issue is with the return type -- thus, we can't overload the method name. This is why, in Lucene.Net, we added Lucene.Net.Store.FSDirectory.GetDirectory() and flaged Lucene.Net.Store.FSDirectory.GetFile() as depreciated. To keep the APIs consistent between Java and Lucene.Net, I'm requesting that Java Lucene add org.apache.lucene.store.FSDirectory.getDirectory(). Add org.apache.lucene.store.FSDirectory.getDirectory() -- Key: LUCENE-2076 URL: https://issues.apache.org/jira/browse/LUCENE-2076 Project: Lucene - Java Issue Type: Wish Components: Store Affects Versions: 3.0 Reporter: George Aroush Priority: Minor Fix For: 3.1 Attachments: FSDirectory.patch On the Apache Lucene.Net side, we have done some clean up with the upcoming 2.9.1 such that we are now depreciating improperly use of parameter type for some public APIs. When we release 3.0, those depreciated code will be removed. One area where we had difficulty with required us to add a new method like so: Lucene.Net.Store.FSDirectory.GetDirectory(). This method does the same thing as Lucene.Net.Store.FSDirectory.GetFile(). This was necessary because we switched over from using System.IO.FileInfo to System.IO.DirectoryInfo. Why? In the .NET world, a file and a directory are two different things. Why did we have to add Lucene.Net.Store.FSDirectory.GetDirectory()? Because we can't change the return type of Lucene.Net.Store.FSDirectory.GetFile() and still remain backward compatible (API wise) to be depreciated with the next release. Why ask for Java Lucene to add org.apache.lucene.store.FSDirectory.getDirectory()? To keep the APIs 1-to-1 in par with Java Lucene and Lucene.Net. -- 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-2076) Add org.apache.lucene.store.FSDirectory.getDirectory()
[ https://issues.apache.org/jira/browse/LUCENE-2076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12779261#action_12779261 ] George Aroush commented on LUCENE-2076: --- Under Lucene.Net 2.9.1, we have depreciated GetFIle, and added GetDirectory. If Java Lucene does the same, can this be done for 3.0? Add org.apache.lucene.store.FSDirectory.getDirectory() -- Key: LUCENE-2076 URL: https://issues.apache.org/jira/browse/LUCENE-2076 Project: Lucene - Java Issue Type: Wish Components: Store Affects Versions: 3.0 Reporter: George Aroush Priority: Minor Fix For: 3.1 Attachments: FSDirectory.patch On the Apache Lucene.Net side, we have done some clean up with the upcoming 2.9.1 such that we are now depreciating improperly use of parameter type for some public APIs. When we release 3.0, those depreciated code will be removed. One area where we had difficulty with required us to add a new method like so: Lucene.Net.Store.FSDirectory.GetDirectory(). This method does the same thing as Lucene.Net.Store.FSDirectory.GetFile(). This was necessary because we switched over from using System.IO.FileInfo to System.IO.DirectoryInfo. Why? In the .NET world, a file and a directory are two different things. Why did we have to add Lucene.Net.Store.FSDirectory.GetDirectory()? Because we can't change the return type of Lucene.Net.Store.FSDirectory.GetFile() and still remain backward compatible (API wise) to be depreciated with the next release. Why ask for Java Lucene to add org.apache.lucene.store.FSDirectory.getDirectory()? To keep the APIs 1-to-1 in par with Java Lucene and Lucene.Net. -- 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-2076) Add org.apache.lucene.store.FSDirectory.getDirectory()
Add org.apache.lucene.store.FSDirectory.getDirectory() -- Key: LUCENE-2076 URL: https://issues.apache.org/jira/browse/LUCENE-2076 Project: Lucene - Java Issue Type: Wish Components: Store Affects Versions: 3.0 Reporter: George Aroush Priority: Minor Fix For: 3.0 On the Apache Lucene.Net side, we have done some clean up with the upcoming 2.9.1 such that we are now depreciating improperly use of parameter type for some public APIs. When we release 3.0, those depreciated code will be removed. One area where we had difficulty with required us to add a new method like so: Lucene.Net.Store.FSDirectory.GetDirectory(). This method does the same thing as Lucene.Net.Store.FSDirectory.GetFile(). This was necessary because we switched over from using System.IO.FileInfo to System.IO.DirectoryInfo. Why? In the .NET world, a file and a directory are two different things. Why did we have to add Lucene.Net.Store.FSDirectory.GetDirectory()? Because we can't change the return type of Lucene.Net.Store.FSDirectory.GetFile() and still remain backward compatible (API wise) to be depreciated with the next release. Why ask for Java Lucene to add org.apache.lucene.store.FSDirectory.getDirectory()? To keep the APIs 1-to-1 in par with Java Lucene and Lucene.Net. -- 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: Optimization and Corruption Issues
Sorry, I'm just catching up with my mailing list inbox, ... Andrzej Bialecki wrote: I used the Luke tool from getopt.org and it worked flawlessly, optimizing the index in just over 2 hours. Problem is that my search cannot use it, and the error states Unknown Format Version errors, or just plain nothing found. You should be careful when using Lucene Java to modify Lucene.Net indexes. I know for a fact that deflated data in Lucene Java is incompatible with the deflater implementation in .Net, so it's easy to create an incompatible index even when you use a supposedly compatible version of Lucene Java. Perhaps versions around 2.0 still worked ok, but no guarantees. Can you please elaborate some more on this? There was a known issue with pre Lucene.Net 2.0.0 where in some instances the index is not compatible with Java Lucene (sorry, I can't find the JIRA issue, but search for PRE_LUCENE_NET_2_0_0_COMPATIBLE in Lucene.Net's code base for details). Other than that, there should NOT be any issues using Java or .NET Lucene to read / write / optimize the index. The same warnings that apply to Java Lucene when moving from version to version also applies to Lucene.Net. This is a test case that I always run as part of a port. Also, a while back, (and I think it's still in production) I helped write a solution in which the index is accessed concurrently by a Java and .NET Lucene 2.1. If you are aware of issues, please bring those to the Lucene.Net mailing list for discussion. Thanks. -- George - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
RE: Porting Java Lucene 2.9 to Lucene.Net (was: RE: Lucene 2.9 RC2 now available for testing)
-Original Message- From: Chris Hostetter [mailto:hossman_luc...@fucit.org] Sent: Monday, August 31, 2009 1:00 AM To: java-dev@lucene.apache.org Subject: Re: Porting Java Lucene 2.9 to Lucene.Net (was: RE: Lucene 2.9 RC2 now available for testing) : My question is, I would prefer to track SVN commits to keep track of : changes, vs. what I'm doing now. This will allow us to stay weeks : behind a Java release vs. months or years as it is now. However, while : I'm subscribed to SVN's commits mailing list, I'm not getting all those : commits! For example, a commit made this past Friday, I never got an : email for, while other commits I do. Any idea what maybe going on? i suggest you track things based on a combination of svn base url (ie: trunk vs a branch) and the specific svn revision number at the moment of your latest checkout -- that way you don't even need to subscribe to the commit list, just do an svn diff -r whenever you have some time to work on it and see what's been committed since the last time you worked on it. Hell: you could probably script all of this and have hudson do it for you. -Hoss What we need is a way to map an SVN commit in Java Lucene to a Lucene.Net JIRA issue. This way, we can track and assign those JIRA issues as port tasks in Lucene.Net world. I don't know much about how SVN revision numbers work. If from SVN revision numbers, we can get back each commit, then this is the best solution (especially if hudson can do it for us). -- George - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
Porting Java Lucene 2.9 to Lucene.Net (was: RE: Lucene 2.9 RC2 now available for testing)
Hi Folks, I have been following the expected release of Lucene.Net 2.9 for some weeks now, and about 2 weeks ago, just before RC1 was released, I grabbed the code off the trunk and started my initial port. Today, I compared what I have with what's in RC2, only 6 Java files changes -- this is good. My question is, I would prefer to track SVN commits to keep track of changes, vs. what I'm doing now. This will allow us to stay weeks behind a Java release vs. months or years as it is now. However, while I'm subscribed to SVN's commits mailing list, I'm not getting all those commits! For example, a commit made this past Friday, I never got an email for, while other commits I do. Any idea what maybe going on? I just sent another subscription request email to SVN commit, but I'm not sure if that will make any difference. Thanks. -- George -Original Message- From: Mark Miller [mailto:markrmil...@gmail.com] Sent: Friday, August 28, 2009 3:19 PM To: java-u...@lucene.apache.org Subject: Re: Lucene 2.9 RC2 now available for testing Mark Miller wrote: Download release candidate 1 here: http://people.apache.org/~markrmiller/staging-area/lucene2.9rc2/ In case anyone catches - yes that is a cut and paste typo - should read release candidate 2 (obvious, but just to cross my t's). -- - Mark http://www.lucidimagination.com - To unsubscribe, e-mail: java-user-unsubscr...@lucene.apache.org For additional commands, e-mail: java-user-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
RE: Porting Java Lucene 2.9 to Lucene.Net (was: RE: Lucene 2.9 RC2 now available for testing)
while I'm subscribed to SVN's commits mailing list, I'm not getting all those commits! For example, a commit made this past Friday, I never got an email for, while other commits I do. Any idea what maybe going on? There has been some flakiness with ASF servers, so maybe that is the reason? Are you using forwarding on people.a.o? No, I'm not using any forwarding. If the code, in the truck, goes through minimal changes for about 2 weeks, I should be fine (until when we figure out the mail issue). -- George - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
RE: Porting Java Lucene 2.9 to Lucene.Net
I have been watching SVN commits for about 2-3 weeks now (since the announcement that the trunk was going to be an RC) during this time, I have not received any email. It was emails from JIRA that hinted me at code checkin's. -- George -Original Message- From: Mark Miller [mailto:markrmil...@gmail.com] Sent: Saturday, August 29, 2009 11:56 AM To: java-dev@lucene.apache.org Subject: Re: Porting Java Lucene 2.9 to Lucene.Net George Aroush wrote: while I'm subscribed to SVN's commits mailing list, I'm not getting all those commits! For example, a commit made this past Friday, I never got an email for, while other commits I do. Any idea what maybe going on? There has been some flakiness with ASF servers, so maybe that is the reason? Are you using forwarding on people.a.o? No, I'm not using any forwarding. If the code, in the truck, goes through minimal changes for about 2 weeks, I should be fine (until when we figure out the mail issue). -- George - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org Have you noticed it happen more than the one time? I've seen similar odd drops on the reg mailing list rarely - a random reply will show up to an original email I never got. Didn't notice it happen enough to claim its anything but bad luck though ;) It makes me wonder what I've missed and not realized though. I'm not forwarding either. bq. If the code, in the truck, goes through minimal changes for about 2 weeks, It should be fairly stable over the next week - bug fixes, build issues, and doc are still fair game, but it should be quite contained and rarely involve code changes (knock on wood). When we unfreeze, there is likely to be rapid development moving towards 3.0 - we will branch off 2.9 before that though, and you will probably want to move from trunk to the branch. -- - 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 - 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 status (to port to Lucene.Net)
Thanks all for your input on this subject. So, if I decide to grab the current code off the trunk, is it: 1) Usable for production use? 2) Is LUCENE-1313 (Realtime search), in the current trunk, stable and ready for use? Put another way, is anyone using the current trunk code in production, or even as beta? -- George _ From: Jason Rutherglen [mailto:jason.rutherg...@gmail.com] Sent: Thursday, April 16, 2009 5:13 PM To: java-dev@lucene.apache.org Subject: Re: Lucene 2.9 status (to port to Lucene.Net) LUCENE-1313 relies on LUCENE-1516 which is in trunk. If you have other questions George, feel free to ask. On Thu, Apr 16, 2009 at 8:04 AM, George Aroush geo...@aroush.net wrote: Thanks Mike. A quick follow up question. What's the status of http://issues.apache.org/jira/browse/LUCENE-1313? Can this work be applied to Lucene 2.4.1 and still get it's benefit or are there other dependency / issues with it that prevents us from doing so? If anyone else knows, I welcome your input. -- George -Original Message- From: Michael McCandless [mailto:luc...@mikemccandless.com] Sent: Thursday, April 16, 2009 8:36 AM To: java-dev@lucene.apache.org Subject: Re: Lucene 2.9 status (to port to Lucene.Net) Hi George, There's been a sudden burst of activity lately on 2.9 development... I know there are some biggish remaining features we may want to get into 2.9: * The new field cache (LUCENE-831; still being iterated/mulled), * Possible major rework of Field / Document index-time vs search-time Document * Applying filters via random-access API when possible performant (LUCENE-1536) * Possible further optimizations to how collection works (LUCENE-1593) * Maybe breaking core + contrib into a more uniform set of modules (and figuring out how Trie(Numeric)RangeQuery/Filter fits in here) -- the Modularization uber-thread. * Further improvements to near-realtime search (using RAMDir for small recently flushed segments) * Many other small things and probably some big ones that I'm forgetting now :) So things are still in flux, and I'm really not sure on a release date at this point. Late last year, I was hoping for early this year, but it's no longer early this year ;) Mike On Wed, Apr 15, 2009 at 9:17 PM, George Aroush geo...@aroush.net wrote: Hi Folks, This is George Aroush, I'm one of the committers on Lucene.Net - a port of Java Lucene to C# Lucene. I'm looking at the current trunk code of yet to be released Lucene 2.9 and I would like to port it to Lucene.Net. If I do this now, we get the benefit of keeping our code base and release dates much closer to Java Lucene. However, this comes with a cost of carrying over unfinished work, known defects, and I have to keep an eye on new code that get committed into Java Lucene which must be ported over in a timely fashion. To help me determine when is a good time to start the port -- keep in mind, I will be taking the latest code off SVN -- I like to hear from the Java Lucene committers (and users who are playing or using Lucene 2.9 off SVN) about those questions: 1) how stable the current code in the trunk is, 2) do you still have feature work to deliver or just bug fixes, and 3) what's your target date to release Java Lucene 2.9 #1 is important, such that is anyone using it in production? Yes, I did look at the current open issues in JIRA, but that doesn't help me answer the above questions. Regards, -- George - 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 - 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 status (to port to Lucene.Net)
Thanks Mike. A quick follow up question. What's the status of http://issues.apache.org/jira/browse/LUCENE-1313? Can this work be applied to Lucene 2.4.1 and still get it's benefit or are there other dependency / issues with it that prevents us from doing so? If anyone else knows, I welcome your input. -- George -Original Message- From: Michael McCandless [mailto:luc...@mikemccandless.com] Sent: Thursday, April 16, 2009 8:36 AM To: java-dev@lucene.apache.org Subject: Re: Lucene 2.9 status (to port to Lucene.Net) Hi George, There's been a sudden burst of activity lately on 2.9 development... I know there are some biggish remaining features we may want to get into 2.9: * The new field cache (LUCENE-831; still being iterated/mulled), * Possible major rework of Field / Document index-time vs search-time Document * Applying filters via random-access API when possible performant (LUCENE-1536) * Possible further optimizations to how collection works (LUCENE-1593) * Maybe breaking core + contrib into a more uniform set of modules (and figuring out how Trie(Numeric)RangeQuery/Filter fits in here) -- the Modularization uber-thread. * Further improvements to near-realtime search (using RAMDir for small recently flushed segments) * Many other small things and probably some big ones that I'm forgetting now :) So things are still in flux, and I'm really not sure on a release date at this point. Late last year, I was hoping for early this year, but it's no longer early this year ;) Mike On Wed, Apr 15, 2009 at 9:17 PM, George Aroush geo...@aroush.net wrote: Hi Folks, This is George Aroush, I'm one of the committers on Lucene.Net - a port of Java Lucene to C# Lucene. I'm looking at the current trunk code of yet to be released Lucene 2.9 and I would like to port it to Lucene.Net. If I do this now, we get the benefit of keeping our code base and release dates much closer to Java Lucene. However, this comes with a cost of carrying over unfinished work, known defects, and I have to keep an eye on new code that get committed into Java Lucene which must be ported over in a timely fashion. To help me determine when is a good time to start the port -- keep in mind, I will be taking the latest code off SVN -- I like to hear from the Java Lucene committers (and users who are playing or using Lucene 2.9 off SVN) about those questions: 1) how stable the current code in the trunk is, 2) do you still have feature work to deliver or just bug fixes, and 3) what's your target date to release Java Lucene 2.9 #1 is important, such that is anyone using it in production? Yes, I did look at the current open issues in JIRA, but that doesn't help me answer the above questions. Regards, -- George - 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 - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
Lucene 2.9 status (to port to Lucene.Net)
Hi Folks, This is George Aroush, I'm one of the committers on Lucene.Net - a port of Java Lucene to C# Lucene. I'm looking at the current trunk code of yet to be released Lucene 2.9 and I would like to port it to Lucene.Net. If I do this now, we get the benefit of keeping our code base and release dates much closer to Java Lucene. However, this comes with a cost of carrying over unfinished work, known defects, and I have to keep an eye on new code that get committed into Java Lucene which must be ported over in a timely fashion. To help me determine when is a good time to start the port -- keep in mind, I will be taking the latest code off SVN -- I like to hear from the Java Lucene committers (and users who are playing or using Lucene 2.9 off SVN) about those questions: 1) how stable the current code in the trunk is, 2) do you still have feature work to deliver or just bug fixes, and 3) what's your target date to release Java Lucene 2.9 #1 is important, such that is anyone using it in production? Yes, I did look at the current open issues in JIRA, but that doesn't help me answer the above questions. Regards, -- George - To unsubscribe, e-mail: java-dev-unsubscr...@lucene.apache.org For additional commands, e-mail: java-dev-h...@lucene.apache.org
[jira] Updated: (LUCENE-707) Lucene Java Site docs
[ https://issues.apache.org/jira/browse/LUCENE-707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] George Aroush updated LUCENE-707: - Attachment: lucene.apache.org.patch Hi Dough, Attached is a patch to add Lucene.Net to TLP of Lucene site. Thanks. -- George Aroush Lucene Java Site docs - Key: LUCENE-707 URL: https://issues.apache.org/jira/browse/LUCENE-707 Project: Lucene - Java Issue Type: Improvement Components: Website Environment: N/A Reporter: Grant Ingersoll Assigned To: Grant Ingersoll Priority: Minor Attachments: lucene.apache.org.patch It would be really nice if the Java site docs where consistent with the rest of the Lucene family (namely, with navigation tabs, etc.) so that one can easily go between Nutch, Hadoop, etc. -- 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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[jira] Commented: (LUCENE-707) Lucene Java Site docs
[ https://issues.apache.org/jira/browse/LUCENE-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12461894 ] George Aroush commented on LUCENE-707: -- Hi, What will it take to fix the page at http://lucene.apache.org/ so that Lucene.Net is also on tab'ed-link? On the 22nd of Nov Otis pointed this out but I still don't see a mention of Lucene.Net. Since Lucene4c is a dead project now, replacing it with Lucene.Net is an appropriate thing to do (Lucene.Net can use some exposure.) The link to Lucene.Net is: http://incubator.apache.org/lucene.net/ Also, as a note, the project name is Lucene.Net and not Lucene.NET. Thanks! -- George Lucene Java Site docs - Key: LUCENE-707 URL: https://issues.apache.org/jira/browse/LUCENE-707 Project: Lucene - Java Issue Type: Improvement Components: Website Environment: N/A Reporter: Grant Ingersoll Assigned To: Grant Ingersoll Priority: Minor It would be really nice if the Java site docs where consistent with the rest of the Lucene family (namely, with navigation tabs, etc.) so that one can easily go between Nutch, Hadoop, etc. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://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-707) Lucene Java Site docs
[ https://issues.apache.org/jira/browse/LUCENE-707?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12461904 ] George Aroush commented on LUCENE-707: -- Thanks for the quick response Grant! Unfortunately, I am not familiar with forrest which is how I believe the patch must be generated. If I supply the required text changes, can someone take care of making the changes? If not, can someone point me to where I can learn about forrest? I believe Doug does have commit privilege. Regards, -- George Lucene Java Site docs - Key: LUCENE-707 URL: https://issues.apache.org/jira/browse/LUCENE-707 Project: Lucene - Java Issue Type: Improvement Components: Website Environment: N/A Reporter: Grant Ingersoll Assigned To: Grant Ingersoll Priority: Minor It would be really nice if the Java site docs where consistent with the rest of the Lucene family (namely, with navigation tabs, etc.) so that one can easily go between Nutch, Hadoop, etc. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: https://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]
Locale string compare: Java vs. C#
Hi folks,
Over at Lucene.Net, I have run into a NUnit test which is failing with
Lucene.Net (C#) but is passing with Lucene (Java). The two tests that fail
are: TestInternationalMultiSearcherSort and TestInternationalSort
After several hours of investigation, I narrowed the problem to what I
believe is a difference in the way Java and .NET implement compare.
The code in question is this method (found in FieldSortedHitQueue.java):
public final int compare (final ScoreDoc i, final ScoreDoc j) {
return collator.compare (index[i.doc], index[j.doc]);
}
To demonstrate the compare problem (Java vs. .NET) I crated this simple code
both in Java and C#:
// Java code: you get back 1 for 'res'
String s1 = H\u00D8T;
String s2 = HUT;
Collator collator = Collator.getInstance (Locale.US);
int diff = collator.compare(s1, s2);
// C# code: you get back -1 for 'res'
string s1 = H\u00D8T;
string s2 = HUT;
System.Globalization.CultureInfo locale = new
System.Globalization.CultureInfo(en-US);
System.Globalization.CompareInfo collator = locale.CompareInfo;
int res = collator.Compare(s1, s2);
Java will give me back a 1 while .NET gives me back -1.
So, what I am trying to figure out is who is doing the right thing? Or am I
missing additional calls before I can compare?
My goal is to understand why the difference exist and thus based on that
understanding I can judge how serious this issue is and find a fix for it or
just document it as a language difference between Java and .NET.
Btw, this is based on Lucene 2.0 for both Java and C# Lucene.
Regards,
-- George Aroush
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: Lucene 2.0.1 release date
Hi folks, Sorry for reposting this question (see original email below) and this time to both mailing list. If anyone can tell me what is the plan for Lucene 2.0.1 release, I would appreciate it very much. As some of you may know, I am the porter of Lucene to Lucene.Net knowing when 2.0.1 will be released will help me plan things out. Regards, -- George Aroush -Original Message- From: George Aroush [mailto:[EMAIL PROTECTED] Sent: Thursday, October 12, 2006 12:07 AM To: java-dev@lucene.apache.org Subject: Lucene 2.0.1 release date Hi folks, What's the plan for Lucene 2.0.1 release date? Thanks! -- George Aroush - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Lucene 2.0.1 release date
Hi folks, What's the plan for Lucene 2.0.1 release date? Thanks! -- George Aroush - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Is it safe to remove the throw from FastCharStream.refill() ?
If I read the JIRA issue right, it look as if this is fixed in Lucene 2.0.1. Is it? If so, where can I download 2.0.1? Thanks! -- George Aroush -Original Message- From: Chris Hostetter [mailto:[EMAIL PROTECTED] Sent: Wednesday, October 04, 2006 3:21 AM To: java-dev@lucene.apache.org Subject: Re: Is it save to remove the throw from FastCharStream.refill() ? : A related prior discussion is at http://issues.apache.org/bugzilla/ : show_bug.cgi?id=34930 Which for the record is: https://issues.apache.org/jira/browse/LUCENE-388 -Hoss - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Is it save to remove the throw from FastCharStream.refill() ?
Hi folks, Over at Lucene.Net, we are trying to determine if it's safe to do the following change: http://issues.apache.org/jira/browse/LUCENENET-8 Can you tell us, if this change is done on the Java Lucene code, how it will effect Lucene? Do you expect the it to run faster but more importantly, is it safe? Thanks. -- George Aroush - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Lucene.NET Jira Emails?
Hi Chris, I don't think this is intentional. Something is broken in the JIRA setup. I have posted this email on general@incubator.apache.org to see if folks there may know what's the problem and fix it. Thanks for noticing -- George -Original Message- From: Chris Hostetter [mailto:[EMAIL PROTECTED] Sent: Saturday, June 17, 2006 4:23 AM To: Lucene Dev; [EMAIL PROTECTED] Subject: Lucene.NET Jira Emails? Is it intentional that the Lucene.NET Jira notifications are being sent to java-dev instead of lucene-net-dev, or is this just a Jira configuration cut/paste mistake? : Date: Sat, 17 Jun 2006 04:34:30 + (GMT+00:00) : From: AqD (JIRA) [EMAIL PROTECTED] : Reply-To: java-dev@lucene.apache.org : To: java-dev@lucene.apache.org : Subject: [jira] Created: (LUCENENET-7) thread local storage bug in 1.9 : RC1 build 4 : : thread local storage bug in 1.9 RC1 build 4 : --- : : Key: LUCENENET-7 : URL: http://issues.apache.org/jira/browse/LUCENENET-7 : Project: Lucene.NET : Type: Bug : : Environment: Windows Server 2003 on VMware, .NET 2.0.50727 : Reporter: AqD : : : Several workarounds for java 1broken thread local storage cause exception in .NET 2 : : Lucene.Net/Index/SegmentReader.cs, line 183 (cause exception) : Lucene.Net/Index/TermInfosReader.cs, line 61 (no exception, but useless?) : : : -- : 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] : -Hoss - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Lucene.NET Jira Emails?
Thanks Hoss. If this is the case, who ever has the karma to fix this, can you take care of it? Also, I can't figure out how to assign, close or even edit a JIRA issue opened against Lucene.Net. For example, take a look at: http://issues.apache.org/jira/browse/LUCENENET-6 and I can't see anything there to edit this issue. Yes, I am logged in. Thanks! -- George -Original Message- From: Chris Hostetter [mailto:[EMAIL PROTECTED] Sent: Saturday, June 17, 2006 12:26 PM To: 'Lucene Dev' Cc: general@incubator.apache.org Subject: RE: Lucene.NET Jira Emails? : I don't think this is intentional. Something is broken in the JIRA setup. : I have posted this email on general@incubator.apache.org to see if folks : there may know what's the problem and fix it. It looks like when the LUCENENET Jira project was setup, the Permission Scheme and Notification Scheme wre set to Lucene Permissions and Lucene Notification Scheme instead of making new ones specific to LUCENENET (perhaps someone assumed the Lucene * Schemes were generic for all projects, not specific to the Lucene Java project) -Hoss - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Test failure question
Hi Simon and all, It's not clear to me when setUp()/tearDown() is called. Are they called before/after each call to testBarelyCloseEnough(), testExact(), testMulipleTerms(), etc? If so, then the NUnit is not doing this. I tested by outputing to stdout. I don't have JUnit setup to see what it does, so if someone who has it setup can test and post here I would really appreciate it. Regards, -- George -Original Message- From: Simon Willnauer [mailto:[EMAIL PROTECTED] Sent: Friday, June 16, 2006 12:39 PM To: java-dev@lucene.apache.org Subject: Re: Test failure question On 6/16/06, George Aroush [EMAIL PROTECTED] wrote: Hi folks, I realize this question is not directly related to Lucene, but I believe it's worth asking. With Lucene.Net (for those who don't know, is a port of Jakarta Lucene from Java to C#) I use NUnit to test the same test code (ported to C#) that JUnit test. When I run the NUnit test there are 3 separate test cases where the test is failing if the test is run as a group but will pass if each of those tests run individually. For example, the tests in TestPhraseQuery, which has testBarelyCloseEnough(), testExact(), testMulipleTerms(), etc. When I run the entire test cases by selecting TestPhraseQuery node, the test starts from the top to bottom and testMulipleTerms() will fail. But if I run testMulipleTerms() by itself it will pass. The fail point is on the first assert line in testMulipleTerms() -- which is (in the NUnit world): Assert.AreEqual(1, hits.Length(), two total moves); My question to you is this: does anyone know if JUnit will call setUP() and tearDown() before and after each test method call or is setUp()/tearDown() are only called once at test startup and shutdown? The fail is, I am getting back a 0, where the expected value should be 1. setUp and tearDown will be called before and after each test runs! http://www.junit.org/junit/javadoc/3.8.1/junit/framework/TestCase.html#setUp () and I bet it is the same in NUnit simon This is rather a junit questing Knowing this will help me diagnoses the problem. Regards, -- George - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Test failure question
Hi Pasha,
That is defiantly not happening in my case. Here is an output:
Setup()
TestBarelyCloseEnough()
TestExact()
TestMulipleTerms()
TestNotCloseEnough()
TestOrderDoesntMatter()
TestPhraseQueryInConjunctionScorer()
TestPhraseQueryWithStopAnalyzer()
TestSlop1()
TestSlopScoring()
TestWrappedPhrase()
TearDown()
Which version of NUnit are you using? I am using 2.2.8.
Regards,
-- George
-Original Message-
From: Pasha Bizhan [mailto:[EMAIL PROTECTED]
Sent: Friday, June 16, 2006 2:07 PM
To: java-dev@lucene.apache.org
Subject: RE: Test failure question
Hi,
testBarelyCloseEnough(), testExact(), testMulipleTerms(), etc? If so,
then the NUnit is not doing this. I tested by outputing to stdout.
NUnit calls setUp before each test and calls tearDown after each test.
Add Console.WriteLine and see the result.
Let me show:
--
[TestFixture]
public class TestPhraseQuery{
[SetUp]
protected void SetUp() {
directory = new RAMDirectory();
IndexWriter writer = new IndexWriter(directory, new
WhitespaceAnalyzer(), true);
...
Console.WriteLine(set up);
}
[TearDown]
protected void TearDown() {
searcher.Close(); directory.Close();
Console.WriteLine(tear down);
}
[Test]
public void TestNotCloseEnough() {
query.SetSlop(2);
.
MockAssert.AreEqual(0, hits.Length());
Console.WriteLine(not close);
}
--
The output:
---
set up
barely
tear down
set up
tear down
...
Pasha Bizhan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
RE: java.util.zip (was Questions about DeleteFile method)
Hi, I am not too excited about using SharpZipLib -- if I use it, unlike now, DotLucene will end up with a 3rd party dependency thus, the port can't be used out of the box. I know, I might not have a better alternative. Regards, -- George Aroush -Original Message- From: Pasha Bizhan [mailto:[EMAIL PROTECTED] Sent: Wednesday, May 04, 2005 1:22 AM To: java-dev@lucene.apache.org Subject: Re: java.util.zip (was Questions about DeleteFile method) Hi, Monsur Hossain [EMAIL PROTECTED] wrote: Hmm, but upon first look I don't see a direct analog to the Inflater/Deflater methods. using ICSharpCode.SharpZipLib.Zip; using ICSharpCode.SharpZipLib.Zip.Compression; // Create the compressor with highest level of compression Deflater compressor = new Deflater(); compressor.SetLevel(Deflater.BEST_COMPRESSION); and etc Pasha Bizhan http://lucenedotnet.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Questions about DeleteFile method
Hi Monsur, I just finished porting SegmentReader.java to C# last night for 1.9 RC1 and I did see your observation -- this is now fixed in RC1. All: Speaking of my port work for 1.9 RC1, I don't have a clear idea what to do about java.util.zip. There is no equivalent in .NET and it is being used in Lucene 1.9 RC1 for Index.FieldsWriter and Index.FieldsReader. Any suggestion? Regards, -- George Aroush -Original Message- From: Monsur Hossain [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 03, 2005 8:18 PM To: java-dev@lucene.apache.org Subject: RE: Questions about DeleteFile method This does happen in the Java version (1.4.3), but I now have a better idea of what's going on. I felt really cool, wrote a big long explanation about it, and then just for kicks checked the code in the Repository. Guess what, it will be fixed in the next version. If you're interested, the issue is in the files() method, around line 219, of Index\SegmentReader.java; in version 1.4.3 there's no check if the file exists before adding it to the Vector. Thanks, Monsur -Original Message- From: Otis Gospodnetic [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 03, 2005 1:26 AM To: java-dev@lucene.apache.org Subject: Re: Questions about DeleteFile method Judging from the method name, this is back in Lucene.Net, so maybe this is a bug in the .Net port. The .cfs file indicates that you are using the compound index format, which means that *.fN files should not be deleted explicitly like that. I wonder if you see the same behaviour with Lucene (Java). Otis --- Monsur Hossain [EMAIL PROTECTED] wrote: So after digging around FSDirectory's DeleteFile method, I noticed something curious. After an incremental index, the system tried to delete a lot of *.f* files (like _5.f1, _5.f2), which didn't exist on the file system. These files are named after the segment that is being deleted (for example, there does exist a _5.cfs file, which is deleted). Why its trying to delete these files that don't exist? Also, when these files aren't found, DeleteFile throws an exception; the calling method traps this exception and adds the filename to the deletable file. This can lead to a lot of exceptions being thrown during a large indexing operation, which could incur a performance penalty. For performance reasons, should DeleteFile return a boolean (true if the file is deleted, false if not), which the calling method can then handle approriately? The calling method would still have to trap on the exception, but at least there'd be far fewer Exceptions thrown. Thanks, Monsur P.s. I haven't done any perf tests to verify this, it was just a thought. I'll look into pulling something together. Simpy -- simpy.com -- tags, social bookmarks, personal search engine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
The Kaourma party: this Saturday
Hi Folks, As far as I know, we have not yet coordinated who and when will be working with the ladies to give them a hand on Saturday. This was one of my agenda for our meeting for Thursday, but since the meeting has been postponed, it is now an outstanding urgent issue. Hikmat: Maybe you already taken care of this, if so, my apology. Regards, -- George - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Lucene 1.9 java.nio in MMapDirectory
Hi Folks, I am looking at Lucene 1.9 RC1 and noticed that MMapDirectory is using java.nio. Isn't java.nio based on Java 1.4? If so, isn't Lucene 1.9 suppose to be backward compatible with Java 1.3? Regards, -- George Aroush - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
