Hi,
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:
https://issues.apache.org/bloodhound/query?owner=$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 = re.search('(?P<n>\d+)weeks?ago',querystring)
>>> int(m.group('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?
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.
Cheers,
Gary
On 29/11/12 00:35, Olemis Lang wrote:
On 11/28/12, Apache Bloodhound <[email protected]> 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 -
http://confluence.jetbrains.com/display/YTD4/Search+and+Command+Attributes#SearchandCommandAttributes-ShortcutKeywords):
* #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 .
;)
