bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Martin <>
Subject Re: [Apache Bloodhound] #654: Rows in ticket query result set not sorted by column
Date Thu, 07 Nov 2013 15:29:17 GMT
Probably best to discuss some of these issues here...

On 04/11/13 16:50, Apache Bloodhound wrote:
> #654: Rows in ticket query result set not sorted by column
> ---------------------------+-----------------------------------
>    Reporter:  olemis        |      Owner:  gjm
>        Type:  defect        |     Status:  accepted
>    Priority:  blocker       |  Milestone:  Release 8
>   Component:  multiproduct  |    Version:
> Resolution:                |   Keywords:  ticket query, sorting
> ---------------------------+-----------------------------------
> Comment (by olemis):
>   Replying to [comment:8 gjm]:
>   > I've been considering this one for a while now. The immediate problem is
>   that lists of enums (Type, Status, Resolution, Priority and Severity for
>   example) are not available as the query to select them is restricted to
>   the product that they are performed in. This makes a bit less sense at the
>   top level where there are none.
>   >
>   > There are a number of ways to deal with this, one of which includes
>   providing an extra variable on the env object to determine whether to
>   force a db_direct_query and decorate the ! method to
>   choose when no product is selected.
>   I do not understand , I've tried something similar to this and still query
>   does not sort tickets by ID are why do we need to add an extra attribute
>   in the environment object ?

Certainly it is not clear that this will fix the issue Olemis 
highlighted but it addresses the ability to order by enum fields. I 
could of course create a new ticket to separate out this work. The extra 
attribute is one of a number of possible solutions. This would be one 
way of swapping to the db_direct_query without modifying trac code. 
Unfortunately, as a query can be expected to get multiple versions of 
enums back, there still needs to be a change to deduplicate - something 
like this somewhere around line 362 of trac/trac/ticket/

    unique = set()
    options = [o for o in options if o not in unique and not unique.add(o)]

Perhaps it would be nicer for the work of this to be handed over to the 

>   The issue mentioned in comment:5 is just about label , I mean , column
>   header is ''Ticket'' whereas values in column are priorities .

I looked to fix based on the observation from Olemis that "Priority 
column header is missing , replaced by Ticket" on bh-demo1 could be 
related. I don't hold out a particular hope of this. I am not convinced 
that I have seen the actual issue that was raised.

>   > This would look something like:
>   > {{{
>   > #!python
>   > import copy
>   > from trac.ticket import model
>   >
>   > from functools import wraps
>   >
>   > def direct_query_override(f):
>   >     @classmethod
>   >     @wraps(f)
>   >     def decorator(cls, env, *args, **kwargs):
>   >         kwargs.pop('db', None)
>   >         denv = copy.copy(env)
>   >         if not getattr(denv, 'product', None):
>   >             denv._db_direct_override = True
>   >         return f.__get__(True).im_func(cls, denv, *args, **kwargs)
>   >     return decorator
>   >
>   > =
>   direct_query_override(
>   > }}}
>   >
>   I'm not sure about this ... IMO we better keep them scoped to a given
>   product and add a separate method to list all enums in all products ,
>   `select_all` ? Notice that there's a case for retrieving all enums in
>   different products .

I think we should be able to appeal to the parent environment for its 
list when that is appropriate but I am not averse to providing the 
ability a little more directly. Currently queries seem to be fully 
scoped anyway so you already need to use a global query for 
cross-product queries.

>   > That still leaves a bit to do about including:
>   >  * duplicate removal
>   +
>   >  * restricting returned values based on permissions
>   +
>   >  * decide whether we care that enums may end up with different
>   priorities in different products
>   Should be important , maybe for highlighting .

Well, sort of - the ordering (and therefore highlighting) is simply 
based on the numeric value. Of course this simplicity means that there 
may be problems to solve when users expect to get equivalence of 
priorities across products with different priority enum sets with common 
members but there is only so much we can do. It is probably a little 
premature to solve the problem but we could:

  * scale the values by the number in each list
  * allow for admins to define gaps in the enum lists
  * make it easy to apply enum schemes to multiple products or for 
products to share definitions

I don't think any of those fully solve the problem though.


View raw message