Hi Peter,
I'm also a Netbeans user, ableit a very happy one who would never
consider eclipse!
The following sequence of steps has worked for me in netbeans 4.0 and
5.0 (haven't upgraded to 5.5 quite yet). The reason for the unusual
directory structure is that Lucene's interleaving of the core an
Vic Bancroft wrote:
>> On Jul 10, 2006, at 11:17 PM, Daniel John Debrunner wrote:
>>
>>> Doug Cutting wrote:
>>>
Since GCJ is effectively available on all platforms, we could say that
we will start accepting 1.5 features when a GCJ release supports those
features. Does that seem
robert engels wrote:
Seems silly to support 1.5 and not do it this way.
Sometimes a little silliness is some serious fun! Just give me a rubber
nose, since I am just clowning around trying to build Andi's kewly
contrib/db using gcj on the slightly stylish db-4.4.20 and je-3.0.12 . . .
O
Agreed. I think those that are reliant on GCJ should plan on
expending the effort to do whatever backporting is needed to make
Lucene work on it. It should also be a GCJ branch or version. Seems
silly to support 1.5 and not do it this way.
On Jul 10, 2006, at 11:17 PM, Daniel John Debrunne
Doug Cutting wrote:
> Since GCJ is effectively available on all platforms, we could say that
> we will start accepting 1.5 features when a GCJ release supports those
> features. Does that seem reasonable?
Seems potentially a little strange to me. Does this mean Lucene would be
limited to the set
Andi Vajda wrote:
On Mon, 10 Jul 2006, Doug Cutting wrote:
Andi Vajda wrote:
On Sat, 8 Jul 2006, Doug Cutting wrote:
Since GCJ is effectively available on all platforms, we could say
that we will start accepting 1.5 features when a GCJ release
supports those features. Does that seem reaso
Creation of the filters is very expense - usually involves a large
range query. We also convert all range and prefix queries to filters
since scoring these does not make sense to us...
For example, show sales where the sales price was > 0 and less than
500k. Frequently the user will get too
Robert,
Can you quantify 'through the roof' a bit? Are the filters that you are
creating that expensive to create or is it the usage of BitSets that are
the real cause of the performance improvement you've seen?
Regards,
Bruce Ritchie
-Original Message-
From: robert engels [mailto:[EM
Random comment...
...
An alternate implementation could use a HashMap to associate term with
maxSegment.
...
Very well taken. :-)
I won't submit a new version of the patch at this point to avoid too
many versions of the patch.
Thanks,
Ning
---
I am trying to contribute to the dot lucene port, but
I am having no luck in getting the tests to compile
and debug for the java version. I tried eclipse and
failed and now I am stuck in Netbean.
More specifically I am using Netbean 5.5 (same
problems with 5.0). My understanding is that it comes
Random comment...
when applying deletes you can break out of the loop early.
+ while (docs.next()) {
+ int doc = docs.doc();
+ if (doc <=
(((DeleteTerm)deleteTerms.elementAt(i)).maxSegment)) {
+ reader.deleteDocument(doc);
+
On Mon, 10 Jul 2006, Doug Cutting wrote:
Andi Vajda wrote:
On Sat, 8 Jul 2006, Doug Cutting wrote:
Since GCJ is effectively available on all platforms, we could say that we
will start accepting 1.5 features when a GCJ release supports those
features. Does that seem reasonable?
+1
If we u
Chris Hostetter wrote on 07/10/2006 12:31 PM:
> So i guess we are on the same page that this kind of thing can be done at
> the App level -- what benefits do you see moving them into the Lucene
> index level?
>
Other than performance per David's and Marvin's ideas, the functionality
benefits
: previously mentioned a very simple one: validating fields in the query
: parser. More interesting examples are:
This strikes me as something that can be done with an abstraction layer
above and seperate from the physical index (this is in fact what Solr
does) without needing to add any hard c
On 7/11/06, Yonik Seeley <[EMAIL PROTECTED]> wrote:
On 7/10/06, David Balmain <[EMAIL PROTECTED]> wrote:
> I don't think declaring all fields up front is necessary for
> substantial optimizations. I've found that the key to some really good
> optimizations is having constant field numbers. That i
On 7/10/06, David Balmain <[EMAIL PROTECTED]> wrote:
I don't think declaring all fields up front is necessary for
substantial optimizations. I've found that the key to some really good
optimizations is having constant field numbers. That is, once a field
is added to the index it is assigned a fie
On 7/11/06, Chuck Williams <[EMAIL PROTECTED]> wrote:
David Balmain wrote on 07/10/2006 01:04 AM:
> The only problem I could find with this solution is that
> fields are no longer in alphabetical order in the term dictionary but
> I couldn't think of a use-case where this is necessary although I'
Yonik Seeley wrote on 07/10/2006 09:27 AM:
> I'll rephrase my original question:
> When implementing NewIndexModifier, what type of efficiencies do we
> get by using the new protected methods of IndexWriter vs using the
> public APIs of IndexReader and IndexWriter?
I won't comment on Ning's imp
On 7/10/06, Chris Hostetter <[EMAIL PROTECTED]> wrote:
[performance stuff]
Is this serious enough to revert?
Definitely not serious at all. It won't even be measurable.
Uncovering bugs that may only have manifested in FSDirectory is more
than enough reason to not revert.
-Yonik
http://incubat
On 7/10/06, Ning Li <[EMAIL PROTECTED]> wrote:
Almost all the Lucene newbies
that I know went through this learning curve of realizing you have to
batch inserts and deletes to achieve good performance.
I agree that having the ability of interleave inserts and deletes to
users of Lucene is a goo
Then I submit hat my proposed "BufferedWriter" is far simpler and
probably performs equally as well, if not better, especially for the
case where a document can be uniquely identified.
On Jul 10, 2006, at 10:47 AM, Ning Li wrote:
You keep stating that you never need to close the IndexWrite
You keep stating that you never need to close the IndexWriter. I
don't believe this is the case, and you are possibly misleading
people as to the extent of your patch.
Don't you need to close (or flush) to get the documents on disk, so
a new IndexReader can find them? If not any documents added
Chris Hostetter wrote on 07/10/2006 02:06 AM:
> As near as i can tell, the large issue can be sumarized with the following
> sentiment:
>
> Performance gains could be realized if Field
> properties were made fixed and homogeneous for
> all Documents in an index.
>
This is cert
David Balmain wrote on 07/10/2006 01:04 AM:
> The only problem I could find with this solution is that
> fields are no longer in alphabetical order in the term dictionary but
> I couldn't think of a use-case where this is necessary although I'm
> sure there probably is one.
So presumably fields ar
You keep stating that you never need to close the IndexWriter. I
don't believe this is the case, and you are possibly misleading
people as to the extent of your patch.
Don't you need to close (or flush) to get the documents on disk, so
a new IndexReader can find them? If not any documents
Andi Vajda wrote:
On Sat, 8 Jul 2006, Doug Cutting wrote:
Since GCJ is effectively available on all platforms, we could say that
we will start accepting 1.5 features when a GCJ release supports those
features. Does that seem reasonable?
+1
If we use this criteria, then we should probably of
: > Are there good reasons this path has not been followed?
:
: Hoss, that's your cue.
I must admit, I haven't been able to fully follow this thread, perhaps
it's just because it's late (no, that can't be it ... i started reading it
at 3:30 this afternoon and then stoped because it was making my
On 7/10/06, Doug Cutting <[EMAIL PROTECTED]> wrote:
Chuck Williams wrote:
> Lucene today allows many field properties to vary at the Field level.
> E.g., the same field name might be tokenized in one Field on a Document
> while it is untokenized in another Field on the same or different
> Documen
: I should metion that there is an upside to the patch it can
: uncover bugs by detecting access after a close(). Before, this would
: have worked with a RAMDirectory, but failed with a FSDirectory.
yeah, seeing that test failure when i made the change locally is what sold
me on commiting it
Chuck Williams wrote:
Lucene today allows many field properties to vary at the Field level.
E.g., the same field name might be tokenized in one Field on a Document
while it is untokenized in another Field on the same or different
Document.
The rationale for this design was to keep the API simp
30 matches
Mail list logo
