You are viewing an historical archive of past issues. Please report new issues to the appropriate project issue tracker on GitHub.

Feature request #1244: Search by tag in issue tracker

Kind feature request
Product wincent.dev
When Created , updated
Status open
Reporter Greg Hurrell
Tags no tags

Description

Would be nice to be able to search by specific tags, for example, "security", within the issue tracker instead of doing a site-wide tag search.

Comments

  1. Greg Hurrell

    Status changed:

    • From: New
    • To: Open
  2. Greg Hurrell

    So this would be another field in the issue search form, basically.

  3. Greg Hurrell

    Made some notes about this earlier.

    As far as tag search on issues only is concerned, this would necessarily involve at least one join on our search query (most likely two, because we'd need to join on both taggings and tags tables to our issues table query).

    Other options I was thinking about included denormalizing (ie. embedding the tag name inside the issues table itself) to avoid the joins altogether, or denormalizing just the tag name into the taggings table. The latter may be more flexible and of general use seeing as lots of models are taggable and searching based on tagging is of use.

    Given some example tables:

    tags:
-----
1 foo
2 bar
3 baz

issues:
--------
1 prob
2 bug
3 defect
4 req

taggings:
id tag_id  taggable_type taggable_id
-----------------------------------
1  1 (foo) issue         1
2  2 (bar) issue         1
3  1 (foo) issue         2
4  3 (baz) issue         3

    If we join our issues table with our (denormalized) taggings table we'll wind up with something like this: 

    issue    tag_id name
--------------------
1 prob   1      foo
1 prob   2      bar
2 bug    1      foo
3 defect 3      baz
4 req    NULL   NULL

    There are two ways to work with such a joined table.

    One is to do a SELECT WHERE the expected attributes match, AND (tag = "foo" OR tag = "bar").

    Just say we're looking for issues tagged with foo and bar, and our query returns two rows for the same issue, we know that both tags were present (ie. "AND" semantics for the tag search).

    If we just do a dumb GROUP BY then we end up with "OR" semantics, which aren't really consistent with how we usually use tags. (ie. we have the concept of narrowing down searches by adding more and more tags to them).

    The other approach is to try and come up with a super "smart" query that doesn't just GROUP BY but actually adds a count of the number of matching tags in another column; eg: 

    issue    tag_id name
--------------------
1 prob   1      foo
1 prob   2      bar

    Would become:

    issue    tag_match_count
------------------------
1 prob   2

    And seeing as we're looking for two tags with "AND" semantics, this would be considered a match.

    Unfortunately this kind of query is usually pretty tricky to do and likely will require a complicate subquery.

Add a comment

Comments are now closed for this issue.

Menu