Re: Lucene 2.1, soon

On 1/19/07, Michael McCandless <[EMAIL PROTECTED]> wrote: I don't think we should hold up 2.1 for this. First, I'm not sure how long it will take me to finish (I have a baby due in 23 days which is making me very nervous!), and second I think we have alot of good stuff already in the trunk to ma

[jira] Resolved: (LUCENE-745) Make inspection of BooleanQuery more efficient

[ https://issues.apache.org/jira/browse/LUCENE-745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley resolved LUCENE-745. - Resolution: Fixed Closing... this patch has already been committed. > Make inspection of Boolean

Re: jruby anyone?

On Jan 19, 2007, at 1:34 PM, Steven Parkes wrote: There are two other pieces: generic rails support (for any rails app, basically akin to ActiveRecord for Lucene) and then there's the app, itself. I see two ways to do this: contrib/jruby/lib (generic juby) /rails (rails support)

Re: JIRA preview and quoting

I cheated... Actually, after losing several long comments when clicking "Add", with some strange 'rights' error, I trust Jira's input area only for very short comments. As soon as a comment gets longer I use my mail client's reply-to, and only when done writing, copy/paste to Jira's text area. So

Re: JIRA preview and quoting

: Alternately, you can reply to a message sent by Jira, but direct the : response to [EMAIL PROTECTED] instead of java-dev, and it should turn into i tested this out at one point and found it to be extremely unreliable .. many messages i sent never made it into Jira, and at several points in the

[jira] Commented: (LUCENE-565) Supporting deleteDocuments in IndexWriter (Code and Performance Results Provided)

[ https://issues.apache.org/jira/browse/LUCENE-565?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466189 ] Jeremy F. Kassis commented on LUCENE-565: - Happy New Year everyone. I'm personally very excited about this im

Re: Payloads

Grant Ingersoll wrote: Couldn't agree more. This is good progress. I like the payloads patch, but I would like to see the lazy prox stream (Lucene 761) stuff done (or at least details given on it) so that we can hook this into Similarity so that it can be hooked into scoring. For 761 and th

Re: Payloads

Marvin Humphrey wrote: On Jan 18, 2007, at 8:31 AM, Michael Busch wrote: I think it makes sense to add new functions incrementally, as long as we try to only extend the API in a way, so that it is compatible with the long-term goal, as Doug suggested already. After the payload patch is commi

Re: JIRA preview and quoting

On Jan 19, 2007, at 2:18 PM, Doug Cutting wrote: Lines starting with '> ' in comments are displayed as quotes. Y'know, I bet I just muffed the cut-and-paste, then. I had composed the message in mail.app, and I've just now verified that the quote characters do not survive the transfer fro

Re: [jira] Commented: (LUCENE-710) Implement "point in time" searching without relying on filesystem semantics

I don't dispute that NFS is used a lot. I think it is VERY debatable as to whether or not NFS is used in Lucene environments. If there are the type of org to be using NFS to begin with, they are probably more accustom to "server" software, and then you can deploy Lucene with any of this non

Re: JIRA preview and quoting

Marvin Humphrey wrote: Hey! How did you manage to get JIRA to use your quoting? When I posted using Firefox for the Mac, it ate mine. Lines starting with '> ' in comments are displayed as quotes. Alternately, you can reply to a message sent by Jira, but direct the response to [EMAIL PROTECT

determining whether a directory is on NFS?

This is a spinoff from the massive thread on how to have Lucene support "point in time" searching on NFS. Does anyone know of a Java friendly way to query a filesystem (well, a directory path) to find out if it's an NFS mount? If there were a way we could give users a clean error/warning messag

[jira] Commented: (LUCENE-710) Implement "point in time" searching without relying on filesystem semantics

[ https://issues.apache.org/jira/browse/LUCENE-710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466165 ] Michael McCandless commented on LUCENE-710: --- Doron Cohen wrote: > This ties solving the NFS issue with an

[jira] Commented: (LUCENE-710) Implement "point in time" searching without relying on filesystem semantics

[ https://issues.apache.org/jira/browse/LUCENE-710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466164 ] Michael McCandless commented on LUCENE-710: --- OK, a few top level summary comments and then some specifics b

Re: JIRA preview and quoting

Marvin Humphrey wrote: On Jan 19, 2007, at 10:56 AM, Doron Cohen (JIRA) wrote: > > Hey! How did you manage to get JIRA to use your quoting? When I posted using Firefox for the Mac, it ate mine. Since there's no preview option (which is kind of suprising, in this "Web 2.0" era), is there

Re: [jira] Commented: (LUCENE-778) Allow overriding a Document

Yes, duh. Was writing and not thinking! On Jan 19, 2007, at 3:49 PM, Chris Hostetter wrote: : Yes, I was suggesting this in light of your suggestions :-) Document : would have to be non-final for this to work. No ... Document as it is with all of it's methods for both being indexed and

Re: [jira] Commented: (LUCENE-778) Allow overriding a Document

: Yes, I was suggesting this in light of your suggestions :-) Document : would have to be non-final for this to work. No ... Document as it is with all of it's methods for both being indexed and for being returned from a search could still be final -- it would just need to impliment these new in

Re: [jira] Commented: (LUCENE-778) Allow overriding a Document

Makes sense... On Jan 19, 2007, at 3:14 PM, Chris Hostetter wrote: : statements, etc.) behind the scene. When you go to add Fieldables to : your document, you would just construct the appropriate DBFieldable : and pass it to add. I think this would solve a lot of people's : issues with co

Re: [jira] Commented: (LUCENE-778) Allow overriding a Document

: statements, etc.) behind the scene. When you go to add Fieldables to : your document, you would just construct the appropriate DBFieldable : and pass it to add. I think this would solve a lot of people's : issues with combining DB's and Lucene, or at least the ability to : index the contents o

Re: Decorative cache (and Hits.setSearcher)

: Perhaps I missunderstand you. The cache will remove the results from : the cache if new documents matchig the query is added to the index, : or if it has been optimized. It is only on delete events that the : cached results are retouched. So what you write does not really : apply. Or? you might

JIRA preview and quoting

On Jan 19, 2007, at 10:56 AM, Doron Cohen (JIRA) wrote: > > Hey! How did you manage to get JIRA to use your quoting? When I posted using Firefox for the Mac, it ate mine. Since there's no preview option (which is kind of suprising, in this "Web 2.0" era), is there a scratch section some

Re: contrib packaging

: is org.apache.lucene.index.facade an OK package? : : or should it be org.apache.lucene.indexfacade? if the classes in the package are all intended to be a Facade on classes in org.apache.lucene.index.*, then org.apache.lucene.index.facade sounds right. -Hoss ---

[jira] Commented: (LUCENE-710) Implement "point in time" searching without relying on filesystem semantics

[ https://issues.apache.org/jira/browse/LUCENE-710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466126 ] Doron Cohen commented on LUCENE-710: > * Second, change how IndexFileDeleter works: have it keep track of >

[jira] Commented: (LUCENE-710) Implement "point in time" searching without relying on filesystem semantics

[ https://issues.apache.org/jira/browse/LUCENE-710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466122 ] Marvin Humphrey commented on LUCENE-710: There are two sections in the previous comment that are supposed to

RE: jruby anyone?

Yeah, I thought Erik might reply. Beyond that, I wondered. As to location, there are a couple of pieces here. I agree that contrib/jruby is too generic for an app but I thought it appropriate for the generic part of the API (that other jruby apps (?) would use). There are two other pieces: generi

[jira] Commented: (LUCENE-710) Implement "point in time" searching without relying on filesystem semantics

[ https://issues.apache.org/jira/browse/LUCENE-710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466117 ] Marvin Humphrey commented on LUCENE-710: (This is a continuation of the discussion from one of the threads qu

[jira] Resolved: (LUCENE-779) behaviour of Lucene in tokenizing - causes query problems

[ https://issues.apache.org/jira/browse/LUCENE-779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otis Gospodnetic resolved LUCENE-779. - Resolution: Invalid This is not a Lucene limitation/bug. Atlassian guys could/should cha

Re: [jira] Commented: (LUCENE-710) Implement "point in time" searching without relying on filesystem semantics

This outline makes sense. Before starting work on this, it may be worth going through JIRA, looking for patches that modify the same classes that this LUCENE-710 issue is likely to modify, and committing those patches before they get broken by LUCENE-710 and other larger modifications. Otis --

Re: [jira] Commented: (LUCENE-778) Allow overriding a Document

I like this idea Hoss. Pure speculation to follow: One of the things I have been playing with the idea of implementing the Fieldable class as what I call DBFieldable. The idea being that the Field is backed by a Database (with the appropriate select statements, etc.) behind the scene. Wh

[jira] Commented: (LUCENE-710) Implement "point in time" searching without relying on filesystem semantics

[ https://issues.apache.org/jira/browse/LUCENE-710?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#action_12466073 ] Michael McCandless commented on LUCENE-710: --- There has been some great design discussions / iterations rece

Re: jruby anyone?

Hi. This is off topic but I think Rubens would make for a nice name :-) (I like his art). Lukas On 1/19/07, Steven Rowe <[EMAIL PROTECTED]> wrote: Steven Parkes wrote: > 3) my luke-like app (luki? lucky? juki? ???) Don't forget there is already Lucli in the sandbox. How about: ruke, rube, rub

Re: jruby anyone?

Steven Parkes wrote: > 3) my luke-like app (luki? lucky? juki? ???) Don't forget there is already Lucli in the sandbox. How about: ruke, rube, ruben, rubene, lucene-in-the-sky-with-ruby :) - To unsubscribe, e-mail: [EMAIL PROTEC

[jira] Updated: (LUCENE-779) behaviour of Lucene in tokenizing - causes query problems

[ https://issues.apache.org/jira/browse/LUCENE-779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Suresh Chandran updated LUCENE-779: --- Attachment: query error.doc > behaviour of Lucene in tokenizing - causes query problems > ---

[jira] Created: (LUCENE-779) behaviour of Lucene in tokenizing - causes query problems

behaviour of Lucene in tokenizing - causes query problems - Key: LUCENE-779 URL: https://issues.apache.org/jira/browse/LUCENE-779 Project: Lucene - Java Issue Type: Improvement

Re: jruby anyone?

Steven, I'm heads-down building a Ruby library (solrb) to access Solr. It currently has some basic capabilities, but will evolve a lot in the near future: I've not worked with JRuby yet myself, but I certainly think what you're up to is good

Re: Lucene 2.1, soon

Otis Gospodnetic wrote: Hi, Actually, I quite-like and agree with Marvin's suggestion. If NFS 4 indeed does work well with Lucene, and NFS 3 does not, then I think it's reasonable to expect people to get NFS 4 to make their Lucene apps work correctly with them. Maybe I got lost in this thre

Re: Lucene 2.1, soon

Chuck Williams wrote: I need to support NFS and would not want to rely on the reader refreshing in X minutes. Setting X too small risks a query failure and setting X too large wastes disk space. X would need to be set for 100% reader availability, implying a large value and a lot of disk space

Re: Lucene 2.1, soon

Doron Cohen wrote: Sounds good to me. So it is IndexFileDeleter that can be used by applications to guarantee "their" NFS-safe behavior, namely preventing premature files deletions. Cool. We can probably sometimes write one such alternative, even in contrib. But, should enabling this way of ex

Re: Lucene 2.1, soon

Hi, Actually, I quite-like and agree with Marvin's suggestion. If NFS 4 indeed does work well with Lucene, and NFS 3 does not, then I think it's reasonable to expect people to get NFS 4 to make their Lucene apps work correctly with them. Maybe I got lost in this thread, but it sounds like the

Re: jruby anyone?

I think this would most definitely be a good addition, and would buy you at least a pint of beer from Erik. You probably want something less generic than contrib/jruby, though. ruke? lurb? yuyhqjndusdsdund? ;) Keeping the "connection" to the index (IndexReader opened) would be nice, esp. for l