lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Hostetter <hossman_luc...@fucit.org>
Subject Re: "Advanced" query language
Date Wed, 04 Jan 2006 20:22:28 GMT
: This example code looks interesting. If I understand
: correctly using this approach requires that builders
: like the "q" QueryObjectBuilder instance must be
: explicitly registered with each and every builder that
: consumes its type of output eg BQOB and FQOB. An

correct.

: provider for the class (Query) at runtime. I presume
: doing it your way is a deliberate design choice in
: order to validate at compile time that a particular
: parser configuration has all of the necessary builders
: in place to support incoming XML. That seems like a

err... more to validate at compile time that some Builder which
wraps another Builder isn't expecting the inner builder to return a Query
when the inner builder is garunteed to only ever return a Filter.  the
situation might still come up where the incoming XML doesn't match the
expectation of hte code, at which point the inner builder can say "i don't
have the attributes/data i need to construct an object, so i'm throwing an
exception"

: reasonable approach.
: If I get some time I'll look at implementing something
: based on this.

two other things about an approach like this that occured to me while
i was trying to sleep are:

1) the Builder interfaces don't need to exactly mirror the object
hierarchy, in some cases what really makes sense is an interface per
"trait" so an interface like a "SloppyBuilder" can be implimented by the
PhraseQueryObjectBuilder and a SpanNearQueryObjectBuilder (which also
impliments SpannyBuilder) so builders that expect the nested XML they get
to contain stuff that has slop can require you register a SloppyBuilder
with them.

2) requiring that each builder be explicitly passed a refrence to a
builder of each type it wants to know about is a pain .. and it might be a
dangerous pain if you're trying to "replace" one builder with another one
-- ie: consider the case where a default set of builders exists, and you
ant to replace all uses of PhraseQuery with a SpanNearQuery ... you
remember to replace/override the delegation in QueryBuilder .. but maybe
there's some other Builder that wraps PhraseQuery's you forgot about.

A static pointer could be stored in the interface itself, so that if you
want to redifine the builder that gets used when you want a
"SloppyBuilder" you just access SloppyBuilder.INSTANCE....

public interface QueryBuilder extends ObjectBuilder {
    public static QueryBuilder INSTANCE;
    public Query process(Node n);
}
public interface SloppyBuilder extends QueryBuilder {
    public static SloppyBuilder INSTANCE;
}

... but that requires a single set of registered ObjectBuilders per JVM,
so i'm not fond of the idea ... but perhaps the someone can think of a way
that the same overall concept could be applied in a more general way.




-Hoss


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


Mime
View raw message