Abstractions?

[Matt Honeycutt <mb...@gmail.com>]

Sorry if a blank message came through, my phone decided to send without
warning...

Anyway, I keep running into difficulty with building and testing the parts
of our system that interface directly with the underlying Lucene API.  I
like to do TDD, and that's difficult since there is no easy way to "mock"
the main lucene objects such as IndexSearcher and IndexReader.

To alleviate this development friction, I'm planning to create an
"abstractions" library that wraps some of the core Lucene.net data types.
I'm picturing this being akin to the approach Microsoft took with providing
abstractions of core ASP.NET classes when they shipped ASP.NET MVC.
Basically, there would be an interface for each (major) concrete type, and a
corresponding wrapper/adapter that wires the interface to the underlying
concrete type.  By coding to the abstractions only, dependent classes should
become much more testable.

Anyway, before I start down this road, I wanted to see what everyone else
thought.  Good idea? Bad idea?

RE: Searching for the Numerals in an Alphanumeric Data

[Digy <di...@gmail.com>]

You can use wildcard searches but they are slow. If I were you, I would
write a custom analyzer to separate tokens as [uche] and [8861].

DIGY.

-----Original Message-----
From: EZEILO,UCHENNA JEREMIAH [mailto:uezeilo@cenbank.org] 
Sent: Wednesday, April 21, 2010 6:26 PM
To: lucene-net-user@lucene.apache.org
Subject: Searching for the Numerals in an Alphanumeric Data

Hi,
What do I need to do in order to be able to search for '8861' in
'uche8861'? Assuming I am not able to separate the data as 'uche' and
'8861'.


Thanks

Searching for the Numerals in an Alphanumeric Data

["EZEILO,UCHENNA JEREMIAH" <ue...@cenbank.org>]

Hi,
What do I need to do in order to be able to search for '8861' in
'uche8861'? Assuming I am not able to separate the data as 'uche' and
'8861'.


Thanks

Re: Abstractions?

[Matt Honeycutt <mb...@gmail.com>]

Hi Glyn,

That's actually the approach I've taken up to now, but we are adding
functionality that's very hard to test with that approach. We are having to
set up repositories for all the various conditons and features we want to
test. It would be easier if we could just setup expectations on the specific
types we need to use.

On Apr 20, 2010 11:00 AM, "Glyn Darkin" <gl...@darkinsystems.com> wrote:

Hi Mat,

In my previous project I used the RAM Directory an created an in memory
index with a limited number of documents. This is a similar style to the way
that Lucene in Action demonstrates the usage of the Lucene API.

These tests also formed a great part of the documentation of the system &
Lucene itself as novice users could inspect the unit tests to see how Lucene
worked.

Regards

Glyn



On 20 Apr 2010, at 16:54, Matt Honeycutt wrote:

> Sorry if a blank message came through, my phone...
Glyn Darkin

Darkin Systems Ltd
Mob: 07961815649
Fax: 08717145065
Web: www.darkinsystems.com

Company No: 6173001
VAT No: 906350835

Re: Abstractions?

[Glyn Darkin <gl...@darkinsystems.com>]

Hi Mat,

In my previous project I used the RAM Directory an created an in memory index with a limited number of documents. This is a similar style to the way that Lucene in Action demonstrates the usage of the Lucene API.

These tests also formed a great part of the documentation of the system & Lucene itself as novice users could inspect the unit tests to see how Lucene worked.

Regards

Glyn


On 20 Apr 2010, at 16:54, Matt Honeycutt wrote:

> Sorry if a blank message came through, my phone decided to send without
> warning...
> 
> Anyway, I keep running into difficulty with building and testing the parts
> of our system that interface directly with the underlying Lucene API.  I
> like to do TDD, and that's difficult since there is no easy way to "mock"
> the main lucene objects such as IndexSearcher and IndexReader.
> 
> To alleviate this development friction, I'm planning to create an
> "abstractions" library that wraps some of the core Lucene.net data types.
> I'm picturing this being akin to the approach Microsoft took with providing
> abstractions of core ASP.NET classes when they shipped ASP.NET MVC.
> Basically, there would be an interface for each (major) concrete type, and a
> corresponding wrapper/adapter that wires the interface to the underlying
> concrete type.  By coding to the abstractions only, dependent classes should
> become much more testable.
> 
> Anyway, before I start down this road, I wanted to see what everyone else
> thought.  Good idea? Bad idea?

Glyn Darkin

Darkin Systems Ltd
Mob: 07961815649
Fax: 08717145065
Web: www.darkinsystems.com

Company No: 6173001
VAT No: 906350835