On Tue, Jan 4, 2011 at 10:49 AM, Peter Mateja <peter.mat...@gmail.com> wrote:
>> I made a request of the community in the Lucere project mailing list
>> to respond with ideas about what an ideal .NET API would look like,
>> and how it would function. Specifically, I was hoping to get
>> pseudo-code examples of how end users would like to use Lucene. Even
>> something as simple as:
>>
>> using(var luceneIndex = new LuceneIndex.Open("C:\foo\bar"))
>> {
>> var hitDocs = from doc in luceneIndex where
>> doc.Field["content"].Match("foo") select doc;
>> }
Hi guys, I know almost nothing of .NET (lucene java developer here),
but I was hoping I could provide some suggestions here to help out.
In glancing at some of the issues surrounding a more ".NET" api, i
couldn't help but notice many of the issues people complain about, are
because lucene.net hasn't implemented lucene 3.0
# lucene 3.0.x is the same feature-wise as lucene 2.9.x, no new features.
# lucene 3.0.x is Java 5, which is almost a different programming
language than Java 4 (2.9.x). This means enums, generics, Closeable,
foreach (instead of Iterators), autoboxing, annotations, etc.
A lot of the issues people have raised seem to be due to the fact that
lucene 2.9.x is in an ancient java version... I think if you ported
3.0, things would look a lot more idiomatic (although surely not
perfect for .NET users, but better!).
For example, taking a glance, I people making the .NET forks actually
doing things like taking the 2.9.x code and converting Field.java to
use enums, which is really a duplication of effort since we did this
in java over a year ago!:
http://svn.apache.org/repos/asf/lucene/java/branches/lucene_3_0/src/java/org/apache/lucene/document/Field.java
So, I'm suggesting that one thing you could consider is to start
focusing on lucene 3.0.x, to also produce a more idiomatic api
automatically, and possibly this would be a good enough improvement to
bring in some developers from those forks.
Separately, I'm trying to understand the syntax you provided about
IDisposable/using. Obviously, as part of your porting process you
could take anything marked Closeable [we marked anything wtih a
.close() as Closeable in Lucene 3.0], and mark it IDisposable, but is
this really the best approach?
For example, the syntax you provided seems like it would encourage
closing the IndexReader and opening a new one for each search
request... yet this is about the biggest no-no you can do with a
lucene index... opening a new IndexReader is very heavy and you should
re-use it across queries and not open/close them often... so in this
case, a more idiomatic API could actually be bad, if it encourages
worst practices...
