2.0 release

classic Classic list List threaded Threaded
17 messages Options
Reply | Threaded
Open this post in threaded view
|

2.0 release

Doug Cutting
Are there any changes folks think we need before we make the 2.0
release?  The major change from 1.9, removal of deprecated items, has
been made.  Anything else critical?

Doug

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: 2.0 release

Karl Wettin-3

28 apr 2006 kl. 00.19 skrev Doug Cutting:

> Are there any changes folks think we need before we make the 2.0  
> release?  The major change from 1.9, removal of deprecated items,  
> has been made.  Anything else critical?

Not critical in any way, but I would not mind if Term and Document  
were interfaces instead of final classes.

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: 2.0 release

Doug Cutting
karl wettin wrote:
> Not critical in any way, but I would not mind if Term and Document  were
> interfaces instead of final classes.

That's not likely to happen before the 2.0 release.  We're looking
high-priority, back-compatible bug fixes at this point.

Doug

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

RE: 2.0 release

Robert Engels
In reply to this post by Doug Cutting
What about making IndexReader & IndexWriter interfaces? Or creating
interfaces for these (IReader & IWriter?), and making all of the classes use
the interfaces?

-----Original Message-----
From: Doug Cutting [mailto:[hidden email]]
Sent: Thursday, April 27, 2006 5:20 PM
To: [hidden email]
Subject: 2.0 release


Are there any changes folks think we need before we make the 2.0
release?  The major change from 1.9, removal of deprecated items, has
been made.  Anything else critical?

Doug

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: 2.0 release

Yonik Seeley
In reply to this post by Doug Cutting
Maybe a fix for
http://issues.apache.org/jira/browse/LUCENE-556
might be warranted?

-Yonik

On 4/27/06, Doug Cutting <[hidden email]> wrote:
> Are there any changes folks think we need before we make the 2.0
> release?  The major change from 1.9, removal of deprecated items, has
> been made.  Anything else critical?
>
> Doug

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: 2.0 release

Doug Cutting
In reply to this post by Robert Engels
Robert Engels wrote:
> What about making IndexReader & IndexWriter interfaces? Or creating
> interfaces for these (IReader & IWriter?), and making all of the classes use
> the interfaces?

I should have been more clear: I'm not asking for new feature requests.
  Rather for known, high-priority, bugs.

Doug

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: 2.0 release

Yonik Seeley
In reply to this post by Robert Engels
On 4/27/06, Robert Engels <[hidden email]> wrote:
> What about making IndexReader & IndexWriter interfaces? Or creating
> interfaces for these (IReader & IWriter?), and making all of the classes use
> the interfaces?

There is a drawback to interfaces too... you can't easily add an extra
method in a back-compatible way like you can with classes by providing
a default implementation.

For example, this enabled adding getPositionIncrement() to Tokenizer,
and adding hasNorms() to IndexReader without breaking any subclasses.

-Yonik
http://incubator.apache.org/solr Solr, the open-source Lucene search server

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: 2.0 release

Chris Hostetter-3
In reply to this post by Doug Cutting

: I should have been more clear: I'm not asking for new feature requests.
:   Rather for known, high-priority, bugs.

I don't know if it's high priority, but LUCENE-546 seems to be a trivial
bug with a trivial fix ("seems to be", i'm judging purely by the patch)

2.0 also seems like the best time to commit the patch in LUCENE-507 ...
assuming the GCJ chages have been vetted.


-Hoss


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: 2.0 release

Chuck Williams-2
In reply to this post by Doug Cutting
Any chance at a last plea for LUCENE-362?  It saves me an enormous
amount of unnecessary allocation for the common case of a single large
compressed field.  It is an expert-level api that needs to be used
carefully, but has no affect on any behavior if you don't use it.

http://issues.apache.org/jira/browse/LUCENE-362

Chuck


Doug Cutting wrote on 04/27/2006 12:19 PM:

> Are there any changes folks think we need before we make the 2.0
> release?  The major change from 1.9, removal of deprecated items, has
> been made.  Anything else critical?
>
> Doug
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: 2.0 release

mikeb
In reply to this post by Robert Engels
I'd like to see LUCENE-396 rolled in (modified StopFilter.java to
increment a tokens position when stopword is
encountered) ... but then again I'm biased!

Thanks, Mike.

-----Original Message-----

> From: Doug Cutting [mailto:[hidden email]]
> Sent: Thursday, April 27, 2006 5:20 PM
> To: [hidden email]
> Subject: 2.0 release
>
>
> Are there any changes folks think we need before we make the 2.0
> release?  The major change from 1.9, removal of deprecated items, has
> been made.  Anything else critical?
>
> Doug
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>  

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: 2.0 release

Doug Cutting
In reply to this post by Doug Cutting
Let's try to coordinate this through Jira.

Can folks please vote for bugs that they'd like to see fixed?

Then, committers, if you think a bug is either urgent enough that we
should not release without it, and/or that it has a patch that is safe
to commit, then please change its "Fix Version" to 2.0.  If reasonable,
commit it and resolve the bug.

Then we can get a succinct list of bugs that we need to fix before we
make the 2.0 release.

Thanks,

Doug

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: 2.0 release

Maxim Patramanskij
In reply to this post by Doug Cutting

Currently,  buffer sizes for BufferedIndexInput and
BufferedIndexOutput are equals and have constant size of 1024 bytes.

When using a database for index persistence, it slowdowns performance much
because of relatively small buffer size. With JDBCDirectory and buffer
size increased from 1Kb to 16Kb I got 200%(3 times) performance
increase for indexing.

What about adding a possibility to change buffer size on runtime, that
client code can set appropriate values depending on what persistence
type for indexing is used?

Max


---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: 2.0 release

Tatu Saloranta
--- Maxim Patramanskij <[hidden email]> wrote:

> Currently,  buffer sizes for BufferedIndexInput and
> BufferedIndexOutput are equals and have constant
> size of 1024 bytes.
>
> When using a database for index persistence, it
> slowdowns performance much
> because of relatively small buffer size. With
> JDBCDirectory and buffer
> size increased from 1Kb to 16Kb I got 200%(3 times)
> performance
> increase for indexing.
>
> What about adding a possibility to change buffer
> size on runtime, that
> client code can set appropriate values depending on
> what persistence
> type for indexing is used?

Adding configurability is good, and also changing the
default value to be bit more optimal would be even
better? Just changing default to 2k or 4k (4k is close
to a physical page size, might be good default?) might
be worth doing as well.
I mean, 90% of users probably use things exactly as
they are configured by default; so this would probably
make many Lucene users happy. ;-)

-+ Tatu +-


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: 2.0 release

Otis Gospodnetic-2
I recall somebody (Doug, I think, but I could be wrong) trying different buffer sizes and reporting insignificant performance changes.  But please provide a patch in the JIRA issue, and people can vote for it, if they like it.

Otis

----- Original Message ----
From: Tatu Saloranta <[hidden email]>
To: [hidden email]; Maxim Patramanskij <[hidden email]>
Sent: Saturday, May 6, 2006 7:11:42 PM
Subject: Re: 2.0 release

--- Maxim Patramanskij <[hidden email]> wrote:

> Currently,  buffer sizes for BufferedIndexInput and
> BufferedIndexOutput are equals and have constant
> size of 1024 bytes.
>
> When using a database for index persistence, it
> slowdowns performance much
> because of relatively small buffer size. With
> JDBCDirectory and buffer
> size increased from 1Kb to 16Kb I got 200%(3 times)
> performance
> increase for indexing.
>
> What about adding a possibility to change buffer
> size on runtime, that
> client code can set appropriate values depending on
> what persistence
> type for indexing is used?

Adding configurability is good, and also changing the
default value to be bit more optimal would be even
better? Just changing default to 2k or 4k (4k is close
to a physical page size, might be good default?) might
be worth doing as well.
I mean, 90% of users probably use things exactly as
they are configured by default; so this would probably
make many Lucene users happy. ;-)

-+ Tatu +-


__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com 

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]





---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: 2.0 release

Murat Yakici

Previously, I replied to another thread on Vectors.
The attached .xsl file which shows avg. msec. for changing buffer sizes,
reported from an experiment on TREC collection.

This might help for a decision.

Cheers,
Murat

> I recall somebody (Doug, I think, but I could be wrong) trying different
> buffer sizes and reporting insignificant performance changes.  But please
> provide a patch in the JIRA issue, and people can vote for it, if they
> like it.
>
> Otis
>
> ----- Original Message ----
> From: Tatu Saloranta <[hidden email]>
> To: [hidden email]; Maxim Patramanskij <[hidden email]>
> Sent: Saturday, May 6, 2006 7:11:42 PM
> Subject: Re: 2.0 release
>
> --- Maxim Patramanskij <[hidden email]> wrote:
>
>> Currently,  buffer sizes for BufferedIndexInput and
>> BufferedIndexOutput are equals and have constant
>> size of 1024 bytes.
>>
>> When using a database for index persistence, it
>> slowdowns performance much
>> because of relatively small buffer size. With
>> JDBCDirectory and buffer
>> size increased from 1Kb to 16Kb I got 200%(3 times)
>> performance
>> increase for indexing.
>>
>> What about adding a possibility to change buffer
>> size on runtime, that
>> client code can set appropriate values depending on
>> what persistence
>> type for indexing is used?
>
> Adding configurability is good, and also changing the
> default value to be bit more optimal would be even
> better? Just changing default to 2k or 4k (4k is close
> to a physical page size, might be good default?) might
> be worth doing as well.
> I mean, 90% of users probably use things exactly as
> they are configured by default; so this would probably
> make many Lucene users happy. ;-)
>
> -+ Tatu +-
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: 2.0 release

Otis Gospodnetic-2
Murat,

The mailing list software strips attachments.  You may want to post this somewhere and send the URL.

Thanks,
Otis

----- Original Message ----
From: [hidden email]
To: [hidden email]
Cc: Otis Gospodnetic <[hidden email]>
Sent: Sunday, May 7, 2006 9:27:34 AM
Subject: Re: 2.0 release


Previously, I replied to another thread on Vectors.
The attached .xsl file which shows avg. msec. for changing buffer sizes,
reported from an experiment on TREC collection.

This might help for a decision.

Cheers,
Murat

> I recall somebody (Doug, I think, but I could be wrong) trying different
> buffer sizes and reporting insignificant performance changes.  But please
> provide a patch in the JIRA issue, and people can vote for it, if they
> like it.
>
> Otis
>
> ----- Original Message ----
> From: Tatu Saloranta <[hidden email]>
> To: [hidden email]; Maxim Patramanskij <[hidden email]>
> Sent: Saturday, May 6, 2006 7:11:42 PM
> Subject: Re: 2.0 release
>
> --- Maxim Patramanskij <[hidden email]> wrote:
>
>> Currently,  buffer sizes for BufferedIndexInput and
>> BufferedIndexOutput are equals and have constant
>> size of 1024 bytes.
>>
>> When using a database for index persistence, it
>> slowdowns performance much
>> because of relatively small buffer size. With
>> JDBCDirectory and buffer
>> size increased from 1Kb to 16Kb I got 200%(3 times)
>> performance
>> increase for indexing.
>>
>> What about adding a possibility to change buffer
>> size on runtime, that
>> client code can set appropriate values depending on
>> what persistence
>> type for indexing is used?
>
> Adding configurability is good, and also changing the
> default value to be bit more optimal would be even
> better? Just changing default to 2k or 4k (4k is close
> to a physical page size, might be good default?) might
> be worth doing as well.
> I mean, 90% of users probably use things exactly as
> they are configured by default; so this would probably
> make many Lucene users happy. ;-)
>
> -+ Tatu +-
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]





---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: 2.0 release

Otis Gospodnetic-2
Duh, sorry for the noise.  I didn't see that attachment in the other message.  It looks like it wasn't stripped after all.

Otis

----- Original Message ----
From: Otis Gospodnetic <[hidden email]>
To: [hidden email]
Sent: Sunday, May 7, 2006 11:08:42 AM
Subject: Re: 2.0 release

Murat,

The mailing list software strips attachments.  You may want to post this somewhere and send the URL.

Thanks,
Otis

----- Original Message ----
From: [hidden email]
To: [hidden email]
Cc: Otis Gospodnetic <[hidden email]>
Sent: Sunday, May 7, 2006 9:27:34 AM
Subject: Re: 2.0 release


Previously, I replied to another thread on Vectors.
The attached .xsl file which shows avg. msec. for changing buffer sizes,
reported from an experiment on TREC collection.

This might help for a decision.

Cheers,
Murat

> I recall somebody (Doug, I think, but I could be wrong) trying different
> buffer sizes and reporting insignificant performance changes.  But please
> provide a patch in the JIRA issue, and people can vote for it, if they
> like it.
>
> Otis
>
> ----- Original Message ----
> From: Tatu Saloranta <[hidden email]>
> To: [hidden email]; Maxim Patramanskij <[hidden email]>
> Sent: Saturday, May 6, 2006 7:11:42 PM
> Subject: Re: 2.0 release
>
> --- Maxim Patramanskij <[hidden email]> wrote:
>
>> Currently,  buffer sizes for BufferedIndexInput and
>> BufferedIndexOutput are equals and have constant
>> size of 1024 bytes.
>>
>> When using a database for index persistence, it
>> slowdowns performance much
>> because of relatively small buffer size. With
>> JDBCDirectory and buffer
>> size increased from 1Kb to 16Kb I got 200%(3 times)
>> performance
>> increase for indexing.
>>
>> What about adding a possibility to change buffer
>> size on runtime, that
>> client code can set appropriate values depending on
>> what persistence
>> type for indexing is used?
>
> Adding configurability is good, and also changing the
> default value to be bit more optimal would be even
> better? Just changing default to 2k or 4k (4k is close
> to a physical page size, might be good default?) might
> be worth doing as well.
> I mean, 90% of users probably use things exactly as
> they are configured by default; so this would probably
> make many Lucene users happy. ;-)
>
> -+ Tatu +-
>
>
> __________________________________________________
> Do You Yahoo!?
> Tired of spam?  Yahoo! Mail has the best spam protection around
> http://mail.yahoo.com
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [hidden email]
> For additional commands, e-mail: [hidden email]
>



---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]





---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]





---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]