Considerations for o.a.l.store.Directory refactoring

[Matt Reynolds <ma...@Qsent.com>]

During some recent testing and work with Lucene, my coworkers and I have
noticed some things in Lucene's guts that I wanted to ask about.

Directory is currently an abstract class that claims in its javadoc that
"Directory is a flat list of files", then goes on to describe non-"flat
list of files" based implementations (JDBC, RAM, etc).  Is it worthwhile
to split out Directory into a top level interface, and possibly have the
existing abstract class be a FileBaseDirectory instead?  My primary
consideration (since I'm new to the code) is the number of references to
methods like "fileExist" on directory, and their usage of those methods.
They look like they won't work with non-file-based Directories (like
DocumentsWriter?).  Is that true?  Pointers?  Tips? :)

It seems like this would be more precise while also allowing for a more
fitting interface (more encapsulated?) for non-file-based
implementations.

Thoughts?  If this is not seen as crazy, I'll work on some patches.

As a side note, are folks here open to cleaning up some of the older
code to use "list" instead of concrete implementations and the like?

Thanks

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org

RE: Considerations for o.a.l.store.Directory refactoring

[Matt Reynolds <ma...@Qsent.com>]

> Directory provides a file abstraction.  That abstraction may be
> implemented in various ways, for example, as a disk-based filesystem,
> with memory-resident datastructures, in a database, etc.  Regardless
of
> how it is implemented, the abstraction refers to the storage units as
> "files", even if they're implemented in memory or a database.

Thanks for the explanation.  I was a bit hasty in my question asking, as
a coworker explained most of this to me shortly after I sent my email ;)
I'll spend some more time in the code and come back later!

Thanks

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org

Re: Considerations for o.a.l.store.Directory refactoring

[Doug Cutting <cu...@apache.org>]

Matt Reynolds wrote:
> Directory is currently an abstract class that claims in its javadoc that
> "Directory is a flat list of files", then goes on to describe non-"flat
> list of files" based implementations (JDBC, RAM, etc).  Is it worthwhile
> to split out Directory into a top level interface, and possibly have the
> existing abstract class be a FileBaseDirectory instead? 

Directory provides a file abstraction.  That abstraction may be 
implemented in various ways, for example, as a disk-based filesystem, 
with memory-resident datastructures, in a database, etc.  Regardless of 
how it is implemented, the abstraction refers to the storage units as 
"files", even if they're implemented in memory or a database.

> My primary
> consideration (since I'm new to the code) is the number of references to
> methods like "fileExist" on directory, and their usage of those methods.
> They look like they won't work with non-file-based Directories (like
> DocumentsWriter?).  Is that true?  Pointers?  Tips? :)

These methods work with all Directory implementations.  (Also, BTW, 
DocumentsWriter is not a Directory implementation, but a primary 
consumer of Directory implementations.  An index lives in a Directory.)

Doug

---------------------------------------------------------------------
To unsubscribe, e-mail: java-dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: java-dev-help@lucene.apache.org