Work at SourceForge, help us to make it a better place! We have an immediate need for a Support Technician in our San Francisco or Denver office.

Close

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

jul-01
wont-fix
nobody
pycon (31)
nobody
General
None
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

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
    
     


Anonymous


Cancel   Add attachments