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 Tue, 04 Dec 2012 14:30:32 GMT

Sorry for my delay in responding to this. I find I have to keep saying 
that I am very happy with the way that search is shaping up. I may make 
a couple of minor corrections to the text shortly but I'd like to make a 
few comments and ask a few questions.

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.

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.

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

to discover relatively simple numeric arguments? Is that considered to 
be better than a weeksago(N) style?

I like the idea of including ranges and the ability to define open and 
closed intervals for ranges. If we are already able to make that 
distinction, I would probably also add the ability to mix open and 
closed syntax so you can include at one end of the range and exclude at 
the other. I am also considering whether we should get a bit closer to 
open and closed interval notation in sets if that is not too confusing 
for users.

Finally, for now at least, it may also be worth making sure we have 
operator precedence defined in that document for completeness.

Anyway, this is all looking very good.


On 29/11/12 00:35, Olemis Lang wrote:
> On 11/28/12, Apache Bloodhound <> wrote:
>> Page "Proposals/BEP-0004/ResourceQuery" was added by andrej
>> Content:
>> -------8<------8<------8<------8<------8<------8<------8<------8<--------
> [...]
>> Resource Query component will provide a !ResourceQuery.query method with the
>> following parameters:
>>   * '''query''': query string e.g. “bla status:closed” or a parsed
>> representation of the query . For more information see [#query_syntax Query
>> syntax].
>>   * '''sort''': optional sorting
>>   * '''boost''': optional list of fields with boost values e.g. {“id”: 1000,
>> “subject” :100, “description”:10}. Used only for score based sorting.
>>   * '''filters''': optional list of terms. Usually can be cached by
>> underlying search framework. For example {“type”: “wiki”}
>>   * '''fields''': list of fields to return
>>   * optional paging fields: '''rows/start''' or '''page/pagesize''' fields
>>   * '''facets''' - optional list of facet terms, can be field or expression.
>> == Resource Query is not a report tool #notreport
>> As it was discussed on dev mailing list, search and query serve a different
>> purpose than reports. Resource Query is not intended not provide complex SQL
>> like expressions linke JOIN, UNION etc. Resource Query will search through
>> flattened resource representation. Query syntax should support issue tracker
>> specifics such as search through attachments, related tickets etc.
> [...]
>> Other functions or meta tags can be used in query. Meta tags can be marked
>> with specific character e.g. “#” (similar to YouTrack special keywords -
>>   * #me - current user
>>   * #my - assigned to me
>>   * #currentProject
>>   * #ticket, #wiki etc.
>>   * date and time helper functions e.g. 2weeksago, 1yearago etc.
> [...]
> This is interesting because it seems to me that these subjects I kept
> from original message overlap with a work I'm trying to finish right
> now ... so, when I have a result I'll follow with two major concrete
> suggestions .
> ;)

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