bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Martin <>
Subject Re: [Apache Bloodhound] Proposals/BEP-0004/ResourceQuery added
Date Wed, 05 Dec 2012 00:53:30 GMT
On 4 December 2012 16:49, Andrej Golcov <> wrote:

> Hi,
> > The addition of a greater variety of keywords (metatags) does seem a
> great idea. It is perhaps worth noting that there is
> > already a certain notion of variable substitution in the current queries
> like this:
> >
> >$USER
> >
> > The character we use to mark these is of no great consequence to me but
> there may be advantages to retaining consistency
> > with that form. On which note we may as well add 'user' as a synonym for
> 'me' and 'my'. It may turn out that it is fine for these
> > to be case insensitive too.
> Agree, it would be good to retain consistency with existing query syntax.

OK, $ may also make a bit more sense as it is something that tends to work
without url encoding in address bars.. only a small advantage of course.

> > 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.
> > The helper functions are perhaps where I got this impression. The syntax
> for these seems interesting as well.
> > Is the suggestion there that we use something like
> >
> >    >>> querystring = '1weekago'
> >    >>> m ='(?P<n>\d+)weeks?ago',querystring)
> >    >>> int('n')) if m is not None else 0
> >    1
> >
> > to discover relatively simple numeric arguments? Is that considered to
> be better than a weeksago(N) style?
> For consistency, I borrowed the syntax for date/time variables from
> TracQuery syntax [1].

Yeah, that makes sense. Shows how much I know!

> Personally, I don't have strong opinion which
> syntax is better but it should be simple for user to type it in search
> box. Another possible alternative that came to my mind is lucene
> syntax [2]

Ah, this explains quite a lot.  I see that the solr/lucene syntax has many
of the features that I wanted to advocate for the range syntax including
mixed open and closed intervals. I was thinking that it might be better to
use '()' for the open intervals which I believe is closer to set interval
syntax. This could give us syntax like:
    [a..b] : range with a and b included (closed interval)
    (a..b): a and b excluded (open interval)
    (a..b]: a excluded, b included

It would also be nice to allow for the definition of a set so that we could
say something like:
    status: in ['assigned', 'accepted', 'review']

Anyway, swapping {} for () is not the worst change in the world and
compatibility with lucene syntax might well be more appropriate in this

It does worry me that it might not be the best idea to support lucene as
well as existing syntax but if there are existing parsers for the lucene
style syntax it may be OK. Perhaps there is a way of using Whoosh to
provide parsing services for us.


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message