lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <>
Subject Re: "Advanced" query language
Date Sat, 31 Dec 2005 01:20:22 GMT

: I'm personally happier to stick with one approach,
: preferably with an existing, standardized interface
: which lets me switch implementations. I didn't really
: want to have to design a general API for parsing XML
: as part of this project.

I'm not suggesting that, I'm just saying that the API people use when
writting ObjectBuilders should be agnostic of the underlying
implimentation -- and a good way to ensure that is to think about how it
*could* be implimented using different parsing methodologies.

: The parser framework was (apart from an annoying bug)
: letting me construct and run this collection of
: objects to create a RAMIndex , populate it, run
: queries and test results.
: In this scenario the parser is used as a generic
: instantiator of different objects using configurable
: choice of ObjectBuilders. That's why I used
: "ObjectBuilder" as the building block not just
: "QueryBuilder".

whoa.  I hadn't even considered the possiblity of using the same
parser/handler registry for doing things like index building.  I thought
you said you "didn't really want to have to design a general API for
parsing XML as part of this project" ?   :)

: ie should we offer:
: 1)  XML Parser implementation independence (via SAX,
: DOM, other interface?)

I think the API should be parser independendant.  but that doesn't mean
there has to be multiple implimentations.

: 3) Support for builders to produce *any* object
: construction (not just queries/filters)?

There's a differnce between producing any java.lang.Object and any Lucene
related "object" (ie: query, filter, document, directory) ... I don't
think it's neccessary to support any java.lang.Object, but I can get on
board the idea of supporting any lucene related objects.  That said, i
still really, Really, REALLY like type safety, and the space of lucene
objects is small enough that having seperate registries and "process"
methods.  As I said regarding Queries/Filters -- the caller is going to
know what they are expecting, so they can call the specific method for the
return object they want.

: 4) Ability for Queries to write to XML (choice of
: parser configs can be used to write Query/Filter
: objects as well as read them?)

I'm in favor of this ... but I think it's orthoginal to the issue of

: 5) Ability for Parser configurations to
: "self-document" the XML structures they are capable of
: parsing? ie produce a schema

I have no opinion on this.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message