Gentlemen,
On Friday 12 January 2007 21:00, Chuck Williams wrote:
>
> Doug Cutting wrote on 01/12/2007 09:49 AM:
> > Marvin Humphrey wrote:
> >> Can you show us some code or pseudo-code for a BooleanScorer that
> >> would use impact-sorted posting lists?
> >
> > Another way to interpret this prop
Doug Cutting wrote on 01/12/2007 09:49 AM:
> Marvin Humphrey wrote:
>> Can you show us some code or pseudo-code for a BooleanScorer that
>> would use impact-sorted posting lists?
>
> Another way to interpret this proposal is index-only: the low-level
> indexing APIs should be general enough to per
Marvin Humphrey wrote:
Can you show us some code or pseudo-code for a BooleanScorer that would
use impact-sorted posting lists?
Another way to interpret this proposal is index-only: the low-level
indexing APIs should be general enough to permit impact-sorted posting
lists, and perhaps an impa
Thanks Grant, I will take a look at this.
> -Original Message-
> From: Grant Ingersoll [mailto:[EMAIL PROTECTED]
> Sent: Thursday, January 11, 2007 8:12 AM
> To: java-dev@lucene.apache.org
> Subject: Re: Beyond Lucene 2.0 Index Design
>
> Hi Jeff,
>
> Wond
y 10, 2007 5:41 PM
> To: java-dev@lucene.apache.org
> Subject: Re: Beyond Lucene 2.0 Index Design
>
> I have a couple of questions about the original post of the
> new index design:
>
> (1) Question on the posting list
> > > f. > ,],...[docN, freq
> &g
IL PROTECTED]
> Sent: Wednesday, January 10, 2007 5:12 PM
> To: java-dev@lucene.apache.org
> Subject: Re: Beyond Lucene 2.0 Index Design
>
> Hi, Jeff,
>
> I like the idea of impact based scoring. However, could you
> elaborate more on why we only need to use single field at
On Jan 11, 2007, at 8:37 PM, Ming Lei wrote:
But practically, the approximation (as in my original
post) should work well enough for large corpus and
relevancy-driven retrieval.
The saving on disk access for large corpus (implies
very long posting list) will be huge by impact-sorted
posting
Marvin,
Several posts back on this thread, I talked about an
algorithm of impact-sorted posting list for
conjunctive boolean query. Your concerns on
impact-sorting in boolean retrieval model is valid.
But practically, the approximation (as in my original
post) should work well enough for large corp
On Jan 11, 2007, at 2:30 PM, jian chen wrote:
It seems to me that the impacted-sorted list makes sense if you are
trying
to do pure vector space based ranking. This is from what I have
read from
the research papers. They all talk about how to optimize the vector
space
model using this imp
I also got the same question. It seems it is very hard to efficiently do
phrase based query.
I think most search engines do phrase based query, or at least appear to be.
So, like in google, the query result must contain all the words user
searched on.
It seems to me that the impacted-sorted list
On Jan 9, 2007, at 6:25 AM, Dalton, Jeffery wrote:
e.
f. ],...[docN, freq
,])
How do you build an efficient PhraseScorer to work with an impact-
sorted posting list?
The way PhraseScorer currently works is: find a doc that contains all
terms, then see if the terms occur consecutively in
Hi Jeff,
Wondering if you (and/or others) would be interested in taking a look
at https://issues.apache.org/jira/browse/LUCENE-662 and vetting the
new interfaces, etc. to see if you could come up w/ a prototype
implementation. This would help move along 662 as it would sort out
some of t
The idea of "impact" and "impact-sorted posting list"
should practically work with boolean model by
approximation in the following way:
(1) Index Structure
Inverted-Index : *
posting-list: + (sorted
by impact)
occurrence: position
(2) Retrieval Algorithm for boolean query "a AND b"
set an impa
ses). In
> > > addition to having fewer posting lists to
> examine,
> > you often don't need
> > > to read to the end of long posting lists when
> > processing with a
> > > score-at-a-time approach (see Anh/Moffat's
> Pruned
> > Query Eva
gt; > score-at-a-time approach (see Anh/Moffat's Pruned
> Query Evaluation Using
> > Pre-Computed Impacts, SIGIR 2006) for details on
> one potential
> > algorithm.
> >
> > I'm not quite sure what you mean when mention
> leaving them out and
>
offat's Pruned
> Query Evaluation Using
> > Pre-Computed Impacts, SIGIR 2006) for details on
> one potential
> > algorithm.
> >
> > I'm not quite sure what you mean when mention
> leaving them out and
> > re-calculating them at merge time.
> >
>
.
- Jeff
> -Original Message-
> From: Marvin Humphrey [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, January 09, 2007 2:58 PM
> To: java-dev@lucene.apache.org
> Subject: Re: Beyond Lucene 2.0 Index Design
>
>
> On Jan 9, 2007, at 6:25 AM, Dalton, Jeffery wrote:
>
when mention leaving them out and
re-calculating them at merge time.
- Jeff
> -Original Message-
> From: Marvin Humphrey [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, January 09, 2007 2:58 PM
> To: java-dev@lucene.apache.org
> Subject: Re: Beyond Lucene 2.0 Index Design
>
>
>
ginal Message-
> From: Marvin Humphrey [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, January 09, 2007 2:58 PM
> To: java-dev@lucene.apache.org
> Subject: Re: Beyond Lucene 2.0 Index Design
>
>
> On Jan 9, 2007, at 6:25 AM, Dalton, Jeffery wrote:
>
> > e.
> >
rers to perform scoring and intersection.
The end product would be a very scalable and flexible solution.
- Jeff
> -Original Message-
> From: Doron Cohen [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, January 09, 2007 5:27 PM
> To: java-dev@lucene.apache.org
> Subject: Re:
Scoring today goes doc-at-a-time - all scorers and term-posting-readers
advance together; once a new doc is processed, scoring of previous docs is
known and final. This allows maintaining a finite size queue for collecting
best hits. Then, for huge collections, having to exhaustively scan all
posti
On Jan 9, 2007, at 6:25 AM, Dalton, Jeffery wrote:
e.
f. ],...[docN, freq
,])
Does the impact have any use after it's used to sort the postings?
Can we leave it out of the index format and recalculate at merge-time?
Marvin Humphrey
Rectangular Research
http://www.rectangular.com/
---
Hi,
I wanted to start some discussion about possible future Lucene file /
index formats. This is an extension to the discussion on Flexible
Lucene Indexing discussed on the wiki:
http://wiki.apache.org/jakarta-lucene/FlexibleIndexing
Note: Related sources are listed at the end.
I would like
[ http://issues.apache.org/jira/browse/LUCENE-734?page=all ]
Michael McCandless resolved LUCENE-734.
---
Resolution: Fixed
>From the last comment, it looks like the 2.0 Lucene core JAR is in maven 1.
> Upload Lucene 2.0 artifacts in the M
reate an account and login.
Yes, thanks. I probably had the page locally cached since I still got the
"immutable" message on the page after creating an account and logging in. Now
it shows up as editable, I'll update the instructions.
> Upload Lucene 2.0 artifacts
negrinv wrote:
there is a third way Doug, and it's for me to stop trying to be polite by
answering all the questions that I am being asked, then nobody will get
upset by my replies. If the decision is for no encryption at field level, I
accept it, but I don't believe it should be externalised. P
negrinv wrote:
there is a third way Doug, and it's for me to stop trying to be polite by
answering all the questions that I am being asked, then nobody will get
upset by my replies. If the decision is for no encryption at field level, I
accept it, but I don't believe it should be externalised. P
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
--
View this message in context:
http://www.nabble.com/Attached-proposed-modifications-to-Lucene-2.0-to-support-Field.Store.Encrypted-tf2727614.html#a7710442
Sent from the
;
> Chuck
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
--
View this message in context:
http://www.nabble.com/Attached-proposed-mo
Mike Klaas wrote on 12/05/2006 11:38 AM:
> On 12/5/06, negrinv <[EMAIL PROTECTED]> wrote:
>
>> Chris Hostetter wrote:
>
>> > If the code was not already in the core, and someone asked about
>> adding it
>> > I would argue against doing so on the grounds that some helpfull
>> utility
>> > methods
Doug Cutting wrote:
So, Victor, do you think this functionality could be reasonably packaged
as an add-on package to Lucene?
Doug, for an answer to most of your questions could you please refer to my
answer to Chris Hostetter [ ... ]
Let me be more direct. Encryption of Lucene fields may be
module.
>
> Doug
>
Doug, for an answer to most of your questions could you please refer to my
answer to Chris Hostetter, Chris makes some valid points:
http://www.nabble.com/Re%3A-Attached-proposed-modifications-to-Lucene-2.0-to-support-F
---
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context: http://www.nabble.com/Attached-
proposed-modifi
On 12/5/06, negrinv <[EMAIL PROTECTED]> wrote:
Chris Hostetter wrote:
> If the code was not already in the core, and someone asked about adding it
> I would argue against doing so on the grounds that some helpfull utility
> methods (possibly in a contrib) would be just as usefull, and would h
as unsuccessful in creating a diff file
because I was picking up all kind of formatting differences as well. If you
scan it quickly you will find that is really very simple and, at least in
its current limited implementation, hardly invasive of Lucene's core. All
the encryption routines are in
robert engels wrote:
I would counter that it is not a compelling feature for MOST users of
Lucene, but it can still be implemented externally using binary fields
for those that require it, and or even easier (and maybe even faster)
using a encrypted filesystem with proper security.
+1
Some u
(For the record: I have delibierately avoided looking at your patch so
far, because i didn't want my opinion on the question of "should Lucene
offer encryption services" to be clouded by any specifics of your
implimentation. That said...)
As it's already been pointed out, an apples to apples com
--
From: Nicolas Lalev�e <[EMAIL PROTECTED]>
Sent: Dec 1, 2006 4:49 AM
To: java-dev@lucene.apache.org
Subject: Re: Attached proposed modifications to Lucene 2.0 to
support
Field.Store.Encrypted
Le Vendredi 1 D�cembre 2006 11:10, negrinv a �crit�:
Nicolas Lalev�e-2 wrote:
Le Vendredi 1 D�cem
gt; Victor
>>
>>
>> Robert Engels wrote:
>>>
>>> Not if running under OSX with encrypted swap turned on ! :)
>>>
>>> -Original Message-
>>>> From: Nicolas Lalev�e <[EMAIL PROTECTED]>
>>>> Sent: Dec 1, 2006 4:49 AM
ct: Re: Attached proposed modifications to Lucene 2.0 to
support
Field.Store.Encrypted
Le Vendredi 1 D�cembre 2006 11:10, negrinv a �crit�:
Nicolas Lalev�e-2 wrote:
Le Vendredi 1 D�cembre 2006 01:33, negrinv a �crit :
Thank you Robert for your commnets. I am inclined to agree
with you,
but
I
: dismay I noticed that JIRA assigned licence to the ASF for the provider
: software. something which I did not intend and which cannot be valid. Can it
: be reversed please?)
the flag can't be modified, but attachments can be deleted, which i have
done for the jar in question.
feel free to rea
: That is a valid consideration Doron, which brings the discussion back to the
: difference between encrypton and security. I believe that security is an end
: application responsability, not Lucene's. For instance, is it possible to
: write the end application so that those stats are hidden from
> From negrinv <[EMAIL PROTECTED]>
> Sent Fri 12/1/2006 1:22 PM
> To java-dev@lucene.apache.org
> Subject Re: Attached proposed modifications to Lucene 2.0 to support
> Field.Store.Encrypted
>
>
> That is a valid consideration Doron, which brings the discuss
n't do it
> from Eclipse, do it from the command-line: svn diff src, or some such.
>
> Otis
>
> - Original Message
> From: negrinv <[EMAIL PROTECTED]>
> To: java-dev@lucene.apache.org
> Sent: Friday, December 1, 2006 5:10:47 AM
> Subject: Re: Attach
ple ;-)
That's my two cents.
-- Joaquin
-Original Message-
>From negrinv <[EMAIL PROTECTED]>
Sent Fri 12/1/2006 1:22 PM
To java-dev@lucene.apache.org
Subject Re: Attached proposed modifications to Lucene 2.0 to support
Field.Store.Encrypted
That is a valid consider
---
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
--
View this message in context:
http://www.nabble.com/Attached-proposed-modifications-to-Lucene-2.0-to-support-Field.Store.Encrypted-tf2727614.html#a7646459
Sent fr
Cryptonomicon, anyone?!
On Dec 1, 2006, at 1:02 PM, Doron Cohen wrote:
Robert Engels <[EMAIL PROTECTED]> wrote on 01/12/2006 09:34:12:
... decrypting such small payloads .. I think it is also subject
to an
easy attack,
In addition, index statistics are still available, right? So one
can
On 12/1/06, negrinv <[EMAIL PROTECTED]> wrote:
I think we should not make too many assumptions about performance until we
can test alternative solutions.
<>
The small payload overhead will be amply offset in my opinion by the ability
to be very selective about what is being encrypted, as opp
If you can't do it from Eclipse, do it
from the command-line: svn diff src, or some such.
Otis
- Original Message
From: negrinv <[EMAIL PROTECTED]>
To: java-dev@lucene.apache.org
Sent: Friday, December 1, 2006 5:10:47 AM
Subject: Re: Attached proposed modification
as Lalev�e <[EMAIL PROTECTED]>
>>Sent: Dec 1, 2006 4:49 AM
>>To: java-dev@lucene.apache.org
>>Subject: Re: Attached proposed modifications to Lucene 2.0 to support
Field.Store.Encrypted
>>
>>Le Vendredi 1 D�cembre 2006 11:10, negrinv a �crit�:
>>> Nicolas Lale
-Original Message-
>>From: Nicolas Lalev�e <[EMAIL PROTECTED]>
>>Sent: Dec 1, 2006 2:20 AM
>>To: java-dev@lucene.apache.org
>>Subject: Re: Attached proposed modifications to Lucene 2.0 to support
Field.Store.Encrypted
>>
>>Le Vendredi 1 D�cembre 2006 01:33,
Robert Engels <[EMAIL PROTECTED]> wrote on 01/12/2006 09:34:12:
> ... decrypting such small payloads .. I think it is also subject to an
easy attack,
In addition, index statistics are still available, right? So one can know
how many docs, which (encrypted) words appear in which docs and exactly
w
Not if running under OSX with encrypted swap turned on ! :)
-Original Message-
>From: Nicolas Lalev�e <[EMAIL PROTECTED]>
>Sent: Dec 1, 2006 4:49 AM
>To: java-dev@lucene.apache.org
>Subject: Re: Attached proposed modifications to Lucene 2.0 to support
>Field.
and store the actual payloads elsewhere, so in
our case your solution is not optimal for us.
-Original Message-
>From: Nicolas Lalev�e <[EMAIL PROTECTED]>
>Sent: Dec 1, 2006 2:20 AM
>To: java-dev@lucene.apache.org
>Subject: Re: Attached proposed modifications to Luc
Le Vendredi 1 Décembre 2006 11:10, negrinv a écrit :
> Nicolas Lalevée-2 wrote:
> > Le Vendredi 1 Décembre 2006 01:33, negrinv a écrit :
> >> Thank you Robert for your commnets. I am inclined to agree with you, but
> >> I
> >> would like to establish first of all if simplicity of implementation is
ne code
or user code.
I cannot test the performance issues until there is an alternative solution
in place. If you have one and you can make it available I will be happy to
give it an impartial test.
Victor
--
View this message in context:
http://www.nabble.com/Attached-proposed-modification
rectory.
> >
> > Far simpler, and if yuou are using encryption to begin with, you are
> > probably encrypting most of the data anyway.
> >
> > -Original Message-
> >
> >>From: negrinv <[EMAIL PROTECTED]>
> >>Sent: Nov 29, 2006 9:4
; > the same reasons adding compression was a bad idea (conclusive comments
>> on
>> > the tail of this issue
>> > http://issues.apache.org/jira/browse/LUCENE-648?page=all). Binary
>> fields
>> > can be used by users to achieve this end. Maybe a contrib with u
egrinv <[EMAIL PROTECTED]>
>>Sent: Nov 29, 2006 9:45 PM
>>To: java-dev@lucene.apache.org
>>Subject: Re: Attached proposed modifications to Lucene 2.0 to support
Field.Store.Encrypted
>>
>>
>>Thank you Luke for your comments and the references you supplied.
[
http://issues.apache.org/jira/browse/LUCENE-734?page=comments#action_12454777 ]
Hoss Man commented on LUCENE-734:
-
FYI: anyone can edit the wiki if you create an account and login.
> Upload Lucene 2.0 artifacts in the Maven 1 reposit
st it
works the other way. I'll check that and report back.
> Upload Lucene 2.0 artifacts in the Maven 1 repository
> -
>
> Key: LUCENE-734
> URL: http://issues.apache.org/jira/browse/LUCENE-
re saying
that things put i nthe maven2 repos were automagically copied to maven1 ... i
guess that's not true afterall.
> Upload Lucene 2.0 artifacts in the Maven 1 repository
> -
>
> Key: LUCENE-734
>
-
>From: negrinv <[EMAIL PROTECTED]>
>Sent: Nov 29, 2006 9:45 PM
>To: java-dev@lucene.apache.org
>Subject: Re: Attached proposed modifications to Lucene 2.0 to support
>Field.Store.Encrypted
>
>
>Thank you Luke for your comments and the references you supplied. I read
Agreed.
-Original Message-
>From: Luke Nezda <[EMAIL PROTECTED]>
>Sent: Nov 29, 2006 8:30 PM
>To: java-dev@lucene.apache.org
>Subject: Re: Attached proposed modifications to Lucene 2.0 to support
>Field.Store.Encrypted
>
>I think that adding encryption suppor
9/06, negrinv <[EMAIL PROTECTED] > wrote:
>>
>>
>> Attached are proposed modifications to Lucene 2.0 to support
>> Field.Store.Encrypted.
>> The rational behind this proposal is simple. Since Lucene can store
data
>> in
>> the index, it effectively makes the
Upload Lucene 2.0 artifacts in the Maven 1 repository
-
Key: LUCENE-734
URL: http://issues.apache.org/jira/browse/LUCENE-734
Project: Lucene - Java
Issue Type: Task
Components
with utility
> methods would be a compromise to preserve this work and make it accessible
> to others, or alternatively just a faq entry with the sample code or
> references to it.
> Luke
>
> On 11/29/06, negrinv <[EMAIL PROTECTED]> wrote:
>>
>>
contrib with utility
methods would be a compromise to preserve this work and make it accessible
to others, or alternatively just a faq entry with the sample code or
references to it.
Luke
On 11/29/06, negrinv <[EMAIL PROTECTED]> wrote:
Attached are proposed modifications to Lucene
Attached are proposed modifications to Lucene 2.0 to support
Field.Store.Encrypted.
The rational behind this proposal is simple. Since Lucene can store data in
the index, it effectively makes the data portable. It is conceivable that
some of the data may be sensitive in nature, hence the option
not applicable for the arguments (String, String, Analyzer)
> error in results.jsp when executing search in the browser (demo from Lucene
that gets released.
> CLONE -QueryParser is not applicable for the arguments (String, String,
> Analyzer) error in results.jsp when executing search in the browser (demo
&
I need to reread the FAQ a few times to remember what's in it. But I'll
do some light rewording to make it less 1.4/1.5 specific.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
: That's the convention we've used in Lucene projects. The idea is that
: users should have to go out of their way to build something named
: lucene-2.0.0.jar, since they're likely to patch things. Only the
: official builds should look like official builds, everything else should
: look like a
Doug Cutting <[EMAIL PROTECTED]> wrote on 18/10/2006 13:03:28:
> Yes, this confuses a lot of folks and probably deserves an FAQ.
To some extent, it is already in the FAQ -
http://wiki.apache.org/jakarta-lucene/LuceneFAQ#head-42361d89c6ea75536ba2780543c60e1fd9c9b682
-
Steven Parkes (JIRA) wrote:
Hmmm ... I've been wondering about this. Turns out that both the svn tag lucene_2_0_0 and
the 2.0.0 src tar ball have "2.0.1-dev" in common-build.xml. I don't know if
this was intentional, so that the someone using the signed binary tar ball would be
clearly disting
if they find it critical?
> CLONE -QueryParser is not applicable for the arguments (String, String,
> Analyzer) error in results.jsp when executing searc
prior to cluttering up Jira with a lot of back and forth
discussion)
FYI: The subversion trunk has fixes for both of the problems you noted.
> CLONE -QueryParser is not applicable for the arguments (String, String,
> Analyzer) error in results.jsp when executing search in the browse
the arguments (String, String,
> Analyzer) error in results.jsp when executing search in the browser (demo
> from L
in results.jsp when executing search in the browser (demo
> from Lucene 2.0)
> --
>
> Key: LUC
CLONE -QueryParser is not applicable for the arguments (String, String,
Analyzer) error in results.jsp when executing search in the browser (demo from
Lucene 2.0
zer)
> error in results.jsp when executing search in the browser (demo from Lucene
> 2.0)
> ---
>
> Key: LUCENE-634
>
QueryParser is not applicable for the arguments (String, String, Analyzer)
error in results.jsp when executing search in the browser (demo from Lucene 2.0
Chris Hostetter wrote:
I believe Doug's suggestion was to hold off just long enough to fix any
egregious bugs, or apply any "safe" patches for bugs that have allready
been fixed but not yet applied.
Yes, that's my intent. I've been hoping that a consensus about which
bugs are urgent will appe
ing, but
is not necessary during cleanup.
Thanks, Luc
-Original Message-
From: Chuck Williams [mailto:[EMAIL PROTECTED]
Sent: vrijdag 19 mei 2006 1:23
To: java-dev@lucene.apache.org
Subject: Re: Lucene 2.0
I think Lucene-561 is in the "egregious" category and it has a patch to
f
I think Lucene-561 is in the "egregious" category and it has a patch to
fix it (be sure to get the most recent of the two). Can this be included?
Chuck
Yonik Seeley wrote on 05/18/2006 10:50 AM:
> On 5/18/06, DM Smith <[EMAIL PROTECTED]> wrote:
>> > at the monent, there are two Jira issues with
: I wouldn't seeing 415 being fixed, but I seem to be missing a way one
: changes "Fix Version".
it's a property that can be changed from the edit screen .. but 415 is
weird, there is no "Edit" link in the Operations nav (as opposed to every
other LUCENE issue i've ever looked at )
-Hoss
On 5/18/06, DM Smith <[EMAIL PROTECTED]> wrote:
> at the monent, there are two Jira issues with a "Fix" version of 2.0 still
> unresolved: LUCENE-556 and LUCENE-546
I wouldn't seeing 415 being fixed, but I seem to be missing a way one
changes "Fix Version".
-Yonik
http://incubator.apache.org/s
Chris Hostetter wrote:
: Could someone enumerate what needs to be done before 2.0 is released.
: From following this thread, it was stated that 2.0 was 1.9 with
: deprecations removed.
: Recently it appears to be becoming much more than that.
I believe Doug's suggestion was to hold off just l
: Could someone enumerate what needs to be done before 2.0 is released.
: From following this thread, it was stated that 2.0 was 1.9 with
: deprecations removed.
: Recently it appears to be becoming much more than that.
I believe Doug's suggestion was to hold off just long enough to fix any
egre
On Thu, 2006-05-18 at 09:41 -0400, Erik Hatcher wrote:
> On May 18, 2006, at 9:19 AM, DM Smith wrote:
> > I'd like to see a 2.0 now and if there are changes then
> > subsequent releases, say 2.0.1 for bugs and 2.1 for changes > to API
> or file structure (e.g. byte count vs char count)
>
> +1 fr
On May 18, 2006, at 9:19 AM, DM Smith wrote:
Could someone enumerate what needs to be done before 2.0 is released.
From following this thread, it was stated that 2.0 was 1.9 with
deprecations removed.
Recently it appears to be becoming much more than that.
Personally, I'd like to see a 2.0 n
Could someone enumerate what needs to be done before 2.0 is released.
From following this thread, it was stated that 2.0 was 1.9 with
deprecations removed.
Recently it appears to be becoming much more than that.
Personally, I'd like to see a 2.0 now and if there are changes then
subsequent rel
Hello,
Will 2.0's similarity scoring formula remain the same as the following?
\sum_{t in q} tf(t in d) * idf(t) * boost(t.field in d) * lengthNorm(t.field in
d)
or what exactly it will be?
--
Best regards,
Charlie
-
To un
[ http://issues.apache.org/jira/browse/LUCENE-500?page=all ]
Yonik Seeley closed LUCENE-500:
---
Fix Version: 2.0
Resolution: Fixed
Assign To: Yonik Seeley
Closing... I think we pretty much covered this.
> Lucene 2.0 requirements - Rem
please ignore this.
> Lucene 2.0 requirements - Remove all deprecated code
>
>
> Key: LUCENE-500
> URL: http://issues.apache.org/jira/browse/LUCENE-500
> Project: Lucene - Java
> Type: Tas
test code (Field creation and BooleanQuery.add() in
TestKipping* and TestRewriting).
Is there someone looking into this, or shall I provide a patch?
> Lucene 2.0 requirements - Remove all deprecated code
>
>
> Key
[
http://issues.apache.org/jira/browse/LUCENE-500?page=comments#action_12371340 ]
Yonik Seeley commented on LUCENE-500:
-
Good catch Daniel... I'll try and get to it later tonight.
> Lucene 2.0 requirements - Remove all depreca
[
http://issues.apache.org/jira/browse/LUCENE-500?page=comments#action_12371327 ]
Daniel Naber commented on LUCENE-500:
-
It seems QueryParser.java has been patched, but not QueryParser.jj.
> Lucene 2.0 requirements - Remove all deprecated c
[
http://issues.apache.org/jira/browse/LUCENE-500?page=comments#action_12371309 ]
Doug Cutting commented on LUCENE-500:
-
+1 for removing the empty directory. It can always be recreated if it is
needed again.
> Lucene 2.0 requirements - Remove
be left in place when other tests become deprecated?
> Lucene 2.0 requirements - Remove all deprecated code
>
>
> Key: LUCENE-500
> URL: http://issues.apache.org/jira/browse/LUCENE-500
> Proj
1 - 100 of 128 matches
Mail list logo
