#1510 Change ticket bins (solr) to ticket filters (mongo)

unreleased
wont-fix
nobody
pycon (30)
General
nobody
2011-07-01
2011-02-16
Mark Ramm
No

The bin creation UI should be something like the general ticket edit UI, and rather than creating a SOLR query, it should create a list of mongo filters, and bin's should be based on mongo queries.

Our current "saved search" implementation should continue to exist, but for "realtime" buckets it should be deprecated in favor of "filters", which will actually be realtime since they are based on mongo data, not SOLR.

Reasons:

  • all the saved searches we actually use (and all the ones I've seen in other projects) are just filters.
  • this will eliminate the need to make solr updates be "near real time"
  • improved UI for creating "bins" that are based on filters with no need for project admins to learn the underlying field names.

The UI should allow multi-select for $in operations, which should be a sufficient replacement for most OR uses.

We'll need to add several indexes for a lot of the common filters, possible examples:

  • (app_config_id, milestone)
  • (app_config_id, status)
  • (app_config_id, status, milestone) -- actually iirc, if this existed, the one above it would not be needed
  • etc

Related

Tickets: #4019

Discussion

  • Dave Brondsema

    Dave Brondsema - 2011-02-16
    • summary: Ticket bins revisited --> Change ticket bins (solr) to ticket filters (mongo)
    • Description has changed:

    Diff:

    --- old 
    +++ new 
    @@ -1,10 +1,18 @@
     The bin creation UI should be something like the general ticket edit UI, and rather than creating a SOLR query, it should create a list of mongo filters, and bin's should be based on mongo queries.
    
    -Our current "saved search" implementation should continue to exist, but for "realtime" buckets it should be deprecated in favor of bins, which will actually be realtime since they are based on mongo data, not SOLR. 
    -
    +Our current "saved search" implementation should continue to exist, but for "realtime" buckets it should be deprecated in favor of "filters", which will actually be realtime since they are based on mongo data, not SOLR. 
    +
     Reasons: 
    
     * all the saved searches we actually use (and all the ones I've seen in other projects) are just filters. 
     * this will eliminate the need to make solr updates be "near real time" 
    -* improved UI for creating "bins" that are based on filters with no need for project admins to learn the underlying field names
    +* improved UI for creating "bins" that are based on filters with no need for project admins to learn the underlying field names.
    +
    +The UI should allow multi-select for $in operations, which should be a sufficient replacement for most OR uses.
    +
    +We'll need to add several indexes for a lot of the common filters, possible examples:
    +* (app_config_id, milestone)
    +* (app_config_id, status)
    +* (app_config_id, status, milestone)  -- actually iirc, if this existed, the one above it would not be needed
    +* etc
    
    • milestone: feb-21 --> backlog

    • Description has changed:

    Diff:

    --- old 
    +++ new 
    @@ -11,6 +11,7 @@
     The UI should allow multi-select for $in operations, which should be a sufficient replacement for most OR uses.
    
     We'll need to add several indexes for a lot of the common filters, possible examples:
    +
     * (app_config_id, milestone)
     * (app_config_id, status)
     * (app_config_id, status, milestone)  -- actually iirc, if this existed, the one above it would not be needed
    
     
  • Rick Copeland - 2011-03-07
    • labels: --> pycon
     

Log in to post a comment.