koji

#258 Make task method drop-down menu dynamic
Closed by tkopecek. Opened by tkopecek.
tkopecek/koji dynamic_methods  into  master

Download 258.patch

Currently methods listed in drop-down menu on 'tasks' web page are
generated from static list. This needs to be updated every time when new
method is added and moreover plugins can't modify this list.

Partial solution is to add server call listTaskMethods returning list of
all methods currently in db and use it for web ui.

Even with the index, this looks like an expensive query, that will be run on every request to the taskinfo page. Have we done any performance testing here?

This doesn't enable us to do any filtering of the result. We have deprecated old methods and changed the names of some of them (buildSRPMFromCVS -> buildSRPMFromSCM). This approach could confuse people by showing older methods that are no longer relevant.

Should there be a way to dynamically add tasks to these categories?

Query probably really have some efficiency problems:

EXPLAIN SELECT method FROM task GROUP BY method ORDER BY method;
                             QUERY PLAN                             
--------------------------------------------------------------------
 Sort  (cost=62.39..62.43 rows=15 width=11)
   Sort Key: method
   ->  HashAggregate  (cost=61.95..62.10 rows=15 width=11)
         Group Key: method
         ->  Seq Scan on task  (cost=0.00..60.96 rows=396 width=11)

What I can do for that is changing to less-readable:

EXPLAIN WITH RECURSIVE t AS (
   SELECT MIN(method) AS method FROM task
   UNION ALL
   SELECT (SELECT MIN(method) FROM task WHERE method > t.method)
   FROM t WHERE t.method IS NOT NULL
   )
SELECT method FROM t WHERE method IS NOT NULL
UNION ALL
SELECT NULL WHERE EXISTS(SELECT 1 FROM task WHERE method IS NULL);
                                                           QUERY PLAN                                                           
--------------------------------------------------------------------------------------------------------------------------------
 Append  (cost=205.55..216.66 rows=101 width=32)
   CTE t
     ->  Recursive Union  (cost=0.88..205.55 rows=101 width=32)
           ->  Result  (cost=0.88..0.89 rows=1 width=0)
                 InitPlan 1 (returns $1)
                   ->  Limit  (cost=0.27..0.88 rows=1 width=11)
                         ->  Index Only Scan using task_by_method on task  (cost=0.27..242.15 rows=396 width=11)
                               Index Cond: (method IS NOT NULL)
           ->  WorkTable Scan on t t_1  (cost=0.00..20.26 rows=10 width=32)
                 Filter: (method IS NOT NULL)
                 SubPlan 3
                   ->  Result  (cost=2.00..2.01 rows=1 width=0)
                         InitPlan 2 (returns $3)
                           ->  Limit  (cost=0.27..2.00 rows=1 width=11)
                                 ->  Index Only Scan using task_by_method on task task_1  (cost=0.27..227.82 rows=132 width=11)
                                       Index Cond: ((method IS NOT NULL) AND (method > t_1.method))
   ->  CTE Scan on t  (cost=0.00..2.02 rows=100 width=32)
         Filter: (method IS NOT NULL)
   ->  Result  (cost=8.07..8.08 rows=1 width=0)
         One-Time Filter: $5
         InitPlan 5 (returns $5)
           ->  Index Only Scan using task_by_method on task task_2  (cost=0.27..8.07 rows=1 width=0)
                 Index Cond: (method IS NULL)

Second one uses only Index-scans (https://wiki.postgresql.org/wiki/Loose_indexscan), so it would be better in real-world. Anyway, comments related to filtering and hiding obsoleted methods seems to point more to plugin API for editing categories, etc. So plugin initialization probably should do this and db can remain untouched. So, do it as part of #176 solution.

Dropping in favor of plugin-based solution.

Pull-Request has been closed by tkopecek
Metadata
None
No Tags
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.