bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Olemis Lang <>
Subject Re: [Apache Bloodhound] Proposals/BEP-0004/ResourceQuery added
Date Tue, 04 Dec 2012 20:49:41 GMT
On 12/4/12, Andrej Golcov <> wrote:
>> I was wondering from the text of the proposal whether there was an
>> intention for these to be possible to use unmarked as well.
>> This might be better to treat as a future enhancement.
> Actually, I didn't intend to propose unmarked meta keywords. Date/time
> helper function should be part of syntax. Probably, I have to clarify
> the proposal regarding this subject.
> What I wanted to propose is to have pluggable query parser where
> plugins can add their own meta keywords and functions.

this is nice to have . Defining syntax in the form of clauses might
help with this since plugins could contribute starting keyword and the
parser will call it back to instantiate this clause on its behalf .

FWIW , this is at some extent possible in TracGViz GViz QL parser . In
there each SQL clause is represented internally by an instance of a
sub-class of tracgviz.gvizql.GVizQLClauseHandler . The exact subclass
is selected by keyword (select, where , ...) . Such instances are
responsible for :

1. accepting the parameters parsed by the underlying
    (operator precedence parser & Pygments lexer)
    e.g. store number in offset class in an instance method
2. use that data wisely ... ;)
3. in theory it would be possible to allow for extensible syntax since
    * underlying parser is extensible
    * internal parsing table may be built incrementally by
      feeding grammar productions over and over .
3a. extensibility in (3) is possible as long as
      operator precedence grammar preconditions hold
3b. however (3) above won't be supported in there considering
      the fact that plugin has to be compatible with Google standard ,
      but , for a use case like search ... definitely possible ;)

... so in general , it's nice to have these kinds of extensibility
introduced by plugins .

However , how much extensible will search syntax should be ?




Blog ES:
Blog EN:

Featured article:

View raw message