[PATCH] Allow TracQueries to order on multiple columns

[david@…]

Currently trac only supports ordering on a single column. I've written a patch which provides the ability to sort on more than one column.

This allows:

[[TicketQuery(max=5,order=priority|somecolumn, desc=0|1, status=open)]]

[david@…]

Add multiple column ordering to trac queries

[Remy Blank]

Looks very nice, thank you!

[Christian Boos]

Some suggestions on the patch:

• type(order) != type([]) should be not isinstance(order, list)
• if order is not None and ...: order = [order] but later [... for o in order] which will fail if order is actually None
• desc = ...
  • 80 cols limit (TracDev/CodingStyle)
  • self.order > self.desc is likely not doing what you think it does (e.g. ['a'] > [0] is True)
• tabs near the end of the patch?

[david@…]

Updated patch

[david@…]

OK, I think I've covered the suggested changes and attached the modified patch.

[Christian Boos]

Well, it seems you uploaded the same trac_ordering.patch again…

[david@…]

Argh. How did I manage that? Anyway…I swear this is the correct patch this time.

[david@…]

Second revision

[david@…]

Well, I noticed that I had moved as_str() unnecessarily, so rev 3 of this patch just drops the movement of that function. Otherwise it is the same as rev 2.

[david@…]

3rd Revision

[Remy Blank]

trac_ordering.3.patch​ makes 4 test cases fail. I have simplified and fixed the patch in 10178-multi-column-order-r10691.patch​, but I have a bad feeling about the change. More specifically, treating the order and desc arguments separately feels wrong, and using a single [(field, desc), ...] list as an order argument would feel more natural. Except for the case where order isn't specified, but desc is, which means to use the default ordering but descending.

Also, the fix in get_default_columns() is currently backward-compatible, but not necessarily the best solution.

Ideas and review welcome.

[Remy Blank]

Fixed and simplified.

[Marcus Lindblom Sonestedt <macke@…>]

How about just adding a ! or ~ prefix to the order fields to indicate that they should be reversed, i.e. something like:

[[TicketQuery(order=priority|~created|resolution)]]

I think the tilde (~) is easier to distinguish from a pipe than the exclamation mark.

Underscore or just a dash are other options.

[Andrew C. Martin <andrew.c.martin@…>]

+1

[Christian Boos]

Good idea, though - is much more intuitive in this situation than ~.

[Remy Blank]

Sounds good. We can keep desc for backward compatibility, and it would only affect the first element in the order list (i.e. for the first element in order, sorting is descending iff the element starts with "-" or desc=1).

[osimons]

Agree. Splitting order and desc is not practical. As cboos said, using minus (order=priority|-created|resolution) is what seems most intuitive for negating the order effect.

Decisions in this ticket also has some bearing on how [query] default_order is implemented in #10425.

[Torbjörn Svensson <azoff@…>]

Multi-order has been integrated in patch for #10425 as requested by osimons.

Remaining work on this issue:

• Define a way for the user to select what columns to order by and if the order is to be reversed.
• Remove limitation in #10425 patch for a single rule (Query.init())
• Enable the test case for multi order.

[Remy Blank]

Moving unfinished stuff post-1.0.

[Craig Silver <notify_craig@…>]

I am new to Trac so maybe I have my versioning mixed up but mine says it's 1.0.1. Does that mean this ticket should already be implemented and released? I tried this in my TracQuery but it doesn't sort by the 2nd field:

order=priority|modified

[osimons]

No, 'version' applies to version used when creating the ticket (or where bug is discovered, or as a marker of similar use). This ticket is still open, scheduled for some future non-specific milestone. To be available for you, a ticket should be 'closed' as 'fixed' and with a 'milestone' earlier or equal to the version you are using.

[Craig Silver <notify_craig@…>]

Thanks for clarifying, osimons. I'm surprised that multi-column sorting is not yet supported. No estimate on its release, I guess?

[anonymous]

Is there a reason that this hasn't been included in a release 4 years after it was completed?

[anonymous]

#ping I like and need that feature (especially for sorting priority and severity) and I would like to know when this can become implemented. Thanks in advance!