bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrej Golcov <>
Subject Re: [Apache Bloodhound] Proposals/BEP-0004/ResourceQuery added
Date Tue, 04 Dec 2012 16:49:39 GMT

> 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:
> 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.

> 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].  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]

> Finally, for now at least, it may also be worth making sure we have operator precedence
defined in that document for completeness.
Good point, will cover this subject in proposal.


Regards, Andrej

View raw message