Reworking the Index Constructor

Ruby Apps Ferret
1

Hey …

I was thinking about the way I need to use the Ferret::Index::Index
Class
and its subclasses … i find it somehow complex … I think this can be
done more easily …

Most of the Time a user needs to open up a index to do queries, the best
way would be to use a IndexReader afaik.

I would suggest to do it that way:

index = Ferret::Index::Index.new( :path => ‘/some/path’,
:readonly => true )

i guess this is far easier than using the Ferret::Index::IndexReader.
Other parameters like auto_flush can be ignored.

Furthermore, reading several indexes should be done like that:

index = Ferret::Index::Index.new( :path => [
‘/some/path’,’/another/path’ ],
:readonly => true )

so you dont need to play around with MultiSearcher or MultiReader
Classes.

And if possible (and if this api isn’t downward compatible anyway) i
would
suggest to drop one ‘Index’ in Ferret::Index::Index

We have a Ferret::Document, a Ferret::Field, so why not have a
Ferret::Index … doesn’t make sense to have a Ferret::Index::Index
Class…
at least in the perspective of a user wanting to use ferret… :slight_smile:

Ben

2

On 8/23/06, Benjamin K. [email protected] wrote:

index = Ferret::Index::Index.new( :path => ‘/some/path’,
:readonly => true )

Actually, all I need to do is make sure that the Index class only
opens a writer on a directory if no index exists. The :readonly
parameter isn’t necessary. I consider this is a bug which I should
fix.

i guess this is far easier than using the Ferret::Index::IndexReader.

Yes it would since you don’t need to open a searcher and handle query
parsing.

Other parameters like auto_flush can be ignored.

I think having the read_only parameter for this isn’t necessary. You’d
only have more parameter checking, not less.

Furthermore, reading several indexes should be done like that:

index = Ferret::Index::Index.new( :path => [ ‘/some/path’,‘/another/path’ ],
:readonly => true )

This I can handle. Will do.

so you dont need to play around with MultiSearcher or MultiReader Classes.

And if possible (and if this api isn’t downward compatible anyway) i would
suggest to drop one ‘Index’ in Ferret::Index::Index

I did toy with this but I was concerned it would be confusing since so
many classes fall under Ferret::Index. What do others think? I also
thought about calling it Ferret::I (inspired by camping)

We have a Ferret::Document, a Ferret::Field, so why not have a
Ferret::Index … doesn’t make sense to have a Ferret::Index::Index Class…
at least in the perspective of a user wanting to use ferret… :slight_smile:

If others agree I will do it.

Cheers,
Dave

3

On Thu, Aug 24, 2006 at 09:20:08AM +1000, David B. wrote:

On 8/23/06, Benjamin K. [email protected] wrote:
[…]

And if possible (and if this api isn’t downward compatible anyway) i would
suggest to drop one ‘Index’ in Ferret::Index::Index

I did toy with this but I was concerned it would be confusing since so
many classes fall under Ferret::Index. What do others think? I also
thought about calling it Ferret::I (inspired by camping)

+1

I already stopped counting the times I did

require ‘ferret’
include Ferret
i = Index.new
NoMethodError: undefined method `new’ for Ferret::Index:Module

Jens

–
webit! Gesellschaft für neue Medien mbH www.webit.de
Dipl.-Wirtschaftsingenieur Jens Krämer [email protected]
Schnorrstraße 76 Tel +49 351 46766 0
D-01069 Dresden Fax +49 351 46766 66