You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bloodhound.apache.org by Anze Staric <an...@gmail.com> on 2013/05/29 11:26:40 UTC
Relations search
When search is used to query tickets based on their relations, one can
enter queries such as
"depedson:#123 OR duplicateof:#427". Which of the possible formats to
specify a ticket should be supported? Currently, one can use #123 or
proda-123 which are both valid wiki links. Should we include more ways
to specify a ticket?
Anze
Re: Relations search
Posted by Joachim Dreimann <jo...@wandisco.com>.
On 29 May 2013 14:28, Anze Staric <an...@gmail.com> wrote:
> > Joachim Dreimann <jo...@wandisco.com> wrote:
> > The other option (#123) should take the user to a disambiguation page /
> > process.
>
> I do not understand, how a disambiguation page could be used as a part
> of writing a search query.
Not at the point of writing the query, but after the user has submitted the
query.
User searches for "#proda-123" -> redirected to ticket.
User searches for "#123" -> shown a disambiguation page. That may just list
all tickets that end in 123, for example: "#proda-123, #prodb-123,
#prodc-123". Style could just be search results.
Remember that search is always global (we had many discussions about this
in the past).
- Joe
> I will however add #proda-123 to the list
> of supported patterns.
>
> On Wed, May 29, 2013 at 1:40 PM, Gary Martin <ga...@wandisco.com>
> wrote:
> > There are a few more long hand versions that it may be worth supporting
> like product:proda:ticket:123
>
> I can add product:proda:ticket:123 and ticket:123 as well. Although
> queries like blockedby:product:proda:ticket:123 seem unlikely.
>
--
Joe Dreimann | *User Experience Designer* | WANdisco<http://www.wandisco.com/>
@jdreimann <https://twitter.com/jdreimann>
Re: Relations search
Posted by Gary Martin <ga...@wandisco.com>.
On 30/05/13 11:23, Anze Staric wrote:
> It is possible, but is an enhancement of bhsearch.
>
> We could extend whoosh query parser to detect which tokens are
> actually TracLinks, use trac formatter to resolve them to resource
> urls and then parse those urls to extract the object we are interested
> in.
>
> If it is a priority, it can be done, but IMO, there are currently many
> other areas that require our attention. I have created a ticket[1] for
> this. If this is important, we can raise its priority and I can have a
> look at it.
>
>
> [1] https://issues.apache.org/bloodhound/ticket/538#ticket
Yeah, that is fine. As a ticket we can let anyone have a look if they
fancy it but I hope that this is useful knowledge we have picked up.
Cheers,
Gary
Re: Relations search
Posted by Anze Staric <an...@gmail.com>.
It is possible, but is an enhancement of bhsearch.
We could extend whoosh query parser to detect which tokens are
actually TracLinks, use trac formatter to resolve them to resource
urls and then parse those urls to extract the object we are interested
in.
If it is a priority, it can be done, but IMO, there are currently many
other areas that require our attention. I have created a ticket[1] for
this. If this is important, we can raise its priority and I can have a
look at it.
[1] https://issues.apache.org/bloodhound/ticket/538#ticket
On Thu, May 30, 2013 at 10:24 AM, Gary Martin <ga...@wandisco.com> wrote:
>
>
> Olemis Lang <ol...@gmail.com> wrote:
>
>>On 5/30/13, Anze Staric <an...@gmail.com> wrote:
>>> Let me clarify, I have a Ticket instance and need to generate all
>>> possible TracLinks, that would, when used in a wiki page, resolve to
>>> the url pointing to the ticket that I started with. If this is
>>> possible with the formatter you mentioned, could you point me to the
>>> module where it is located, so I can check it out?
>>>
>>
>>No, no ... I misunderstood your intentions . I thought you were trying
>>to do the opposite . IMHO what you'd like to achieve is impossible in
>>theory ; at least not without introducing a lot of extra code ... or
>>reducing problem scope to a well-known set of TracLinks providers .
>
> For the purposes of searching, I would have thought you would only need to know what the object is rather than what the possible representations are.
>
> Cheers,
> Gary
Re: Relations search
Posted by Gary Martin <ga...@wandisco.com>.
Olemis Lang <ol...@gmail.com> wrote:
>On 5/30/13, Anze Staric <an...@gmail.com> wrote:
>> Let me clarify, I have a Ticket instance and need to generate all
>> possible TracLinks, that would, when used in a wiki page, resolve to
>> the url pointing to the ticket that I started with. If this is
>> possible with the formatter you mentioned, could you point me to the
>> module where it is located, so I can check it out?
>>
>
>No, no ... I misunderstood your intentions . I thought you were trying
>to do the opposite . IMHO what you'd like to achieve is impossible in
>theory ; at least not without introducing a lot of extra code ... or
>reducing problem scope to a well-known set of TracLinks providers .
For the purposes of searching, I would have thought you would only need to know what the object is rather than what the possible representations are.
Cheers,
Gary
Re: Relations search
Posted by Olemis Lang <ol...@gmail.com>.
On 5/30/13, Anze Staric <an...@gmail.com> wrote:
> Let me clarify, I have a Ticket instance and need to generate all
> possible TracLinks, that would, when used in a wiki page, resolve to
> the url pointing to the ticket that I started with. If this is
> possible with the formatter you mentioned, could you point me to the
> module where it is located, so I can check it out?
>
No, no ... I misunderstood your intentions . I thought you were trying
to do the opposite . IMHO what you'd like to achieve is impossible in
theory ; at least not without introducing a lot of extra code ... or
reducing problem scope to a well-known set of TracLinks providers .
--
Regards,
Olemis.
Re: Relations search
Posted by Anze Staric <an...@gmail.com>.
Let me clarify, I have a Ticket instance and need to generate all
possible TracLinks, that would, when used in a wiki page, resolve to
the url pointing to the ticket that I started with. If this is
possible with the formatter you mentioned, could you point me to the
module where it is located, so I can check it out?
On Thu, May 30, 2013 at 5:08 AM, Olemis Lang <ol...@gmail.com> wrote:
> On 5/29/13, Anze Staric <an...@gmail.com> wrote:
>> On Wed, May 29, 2013 at 6:12 PM, Gary Martin <ga...@wandisco.com>
>> wrote:
>>> I'm actually hoping that there is a quick way to collect all the existing
>>> patterns of relevance rather than worrying about justifying whether to
>>> include them. This should also help if there are any future additions to
>>> syntax for any reason.
>>
>> It would be great, if we could automatically generate all possible
>> TracLinks that resolve to a specific resource and then index all those
>> representations, but I do not know, if this is possible.
>>
> [...]
>
> @anze : I'm not sure I understood your statement correctly but afaicr
> there's a Trac formatter able to extract links .
>
> --
> Regards,
>
> Olemis.
Re: Relations search
Posted by Olemis Lang <ol...@gmail.com>.
On 5/29/13, Anze Staric <an...@gmail.com> wrote:
> On Wed, May 29, 2013 at 6:12 PM, Gary Martin <ga...@wandisco.com>
> wrote:
>> I'm actually hoping that there is a quick way to collect all the existing
>> patterns of relevance rather than worrying about justifying whether to
>> include them. This should also help if there are any future additions to
>> syntax for any reason.
>
> It would be great, if we could automatically generate all possible
> TracLinks that resolve to a specific resource and then index all those
> representations, but I do not know, if this is possible.
>
[...]
@anze : I'm not sure I understood your statement correctly but afaicr
there's a Trac formatter able to extract links .
--
Regards,
Olemis.
Re: Relations search
Posted by Anze Staric <an...@gmail.com>.
On Wed, May 29, 2013 at 6:12 PM, Gary Martin <ga...@wandisco.com> wrote:
> I'm actually hoping that there is a quick way to collect all the existing
> patterns of relevance rather than worrying about justifying whether to
> include them. This should also help if there are any future additions to
> syntax for any reason.
It would be great, if we could automatically generate all possible
TracLinks that resolve to a specific resource and then index all those
representations, but I do not know, if this is possible.
> It may be that this kind of query becomes more useful as the number of
> tickets involved grows. Something useful to know might be all the tickets
> that block another ticket but are not blocked. Perhaps I should check if
> this kind of thing has already been implemented!
If you use relation dependson/dependent to mark your blokers, the
following query will return tickets that block other tickets, but are
not blocked themselves:
dependent:* AND NOT dependson:*
Re: Relations search
Posted by Gary Martin <ga...@wandisco.com>.
On 29/05/13 14:28, Anze Staric wrote:
>> Joachim Dreimann <jo...@wandisco.com> wrote:
>> The other option (#123) should take the user to a disambiguation page /
>> process.
> I do not understand, how a disambiguation page could be used as a part
> of writing a search query. I will however add #proda-123 to the list
> of supported patterns.
>
> On Wed, May 29, 2013 at 1:40 PM, Gary Martin <ga...@wandisco.com> wrote:
>> There are a few more long hand versions that it may be worth supporting like product:proda:ticket:123
> I can add product:proda:ticket:123 and ticket:123 as well. Although
> queries like blockedby:product:proda:ticket:123 seem unlikely.
I'll attempt to avoid the temptation to say anything more on the first
part with the hope that Joe will clarify what he means.
I agree that the query you specified might be rare - in fact I wonder if
a query of this type would be very rare anyway given that it doesn't
take too long to get to a ticket and look at the relations that are
specified there.
I'm actually hoping that there is a quick way to collect all the
existing patterns of relevance rather than worrying about justifying
whether to include them. This should also help if there are any future
additions to syntax for any reason.
It may be that this kind of query becomes more useful as the number of
tickets involved grows. Something useful to know might be all the
tickets that block another ticket but are not blocked. Perhaps I should
check if this kind of thing has already been implemented!
Cheers,
Gary
Re: Relations search
Posted by Anze Staric <an...@gmail.com>.
> Joachim Dreimann <jo...@wandisco.com> wrote:
> The other option (#123) should take the user to a disambiguation page /
> process.
I do not understand, how a disambiguation page could be used as a part
of writing a search query. I will however add #proda-123 to the list
of supported patterns.
On Wed, May 29, 2013 at 1:40 PM, Gary Martin <ga...@wandisco.com> wrote:
> There are a few more long hand versions that it may be worth supporting like product:proda:ticket:123
I can add product:proda:ticket:123 and ticket:123 as well. Although
queries like blockedby:product:proda:ticket:123 seem unlikely.
Re: Relations search
Posted by Gary Martin <ga...@wandisco.com>.
Joachim Dreimann <jo...@wandisco.com> wrote:
>The only valid way to specify a ticket should be the fully qualified
>one:
>
>#proda-123
>
>The other option (#123) should take the user to a disambiguation page /
>process.
So, to clarify, you mean it is fine to support the syntax as long as it shows all the results with a process to distinguish them?
There are a few more long hand versions that it may be worth supporting like product:proda:ticket:123
>
>
>On 29 May 2013 10:26, Anze Staric <an...@gmail.com> wrote:
>
>> When search is used to query tickets based on their relations, one
>can
>> enter queries such as
>> "depedson:#123 OR duplicateof:#427". Which of the possible formats to
>> specify a ticket should be supported? Currently, one can use #123 or
>> proda-123 which are both valid wiki links. Should we include more
>ways
>> to specify a ticket?
>>
>>
>> Anze
>>
I am wondering about all the forms for the search syntax as we probably want a set of short, fairly predictable (consistent) terms to make it easy to remember. Either that or lots of synonyms!
Cheers,
Gary
Re: Relations search
Posted by Joachim Dreimann <jo...@wandisco.com>.
The only valid way to specify a ticket should be the fully qualified one:
#proda-123
The other option (#123) should take the user to a disambiguation page /
process.
On 29 May 2013 10:26, Anze Staric <an...@gmail.com> wrote:
> When search is used to query tickets based on their relations, one can
> enter queries such as
> "depedson:#123 OR duplicateof:#427". Which of the possible formats to
> specify a ticket should be supported? Currently, one can use #123 or
> proda-123 which are both valid wiki links. Should we include more ways
> to specify a ticket?
>
>
> Anze
>
--
Joe Dreimann | *User Experience Designer* | WANdisco<http://www.wandisco.com/>
@jdreimann <https://twitter.com/jdreimann>
*
*
*Join one of our free daily demo sessions on* *Scaling Subversion for the
Enterprise <http://www.wandisco.com/training/webinars>*
THIS MESSAGE AND ANY ATTACHMENTS ARE CONFIDENTIAL, PROPRIETARY, AND MAY BE
PRIVILEGED. If this message was misdirected, WANdisco, Inc. and its
subsidiaries, ("WANdisco") does not waive any confidentiality or privilege.
If you are not the intended recipient, please notify us immediately and
destroy the message without disclosing its contents to anyone. Any
distribution, use or copying of this e-mail or the information it contains
by other than an intended recipient is unauthorized. The views and
opinions expressed in this e-mail message are the author's own and may not
reflect the views and opinions of WANdisco, unless the author is authorized
by WANdisco to express such views or opinions on its behalf. All email
sent to or from this address is subject to electronic storage and review by
WANdisco. Although WANdisco operates anti-virus programs, it does not
accept responsibility for any damage whatsoever caused by viruses being
passed.