Ticket Links

This describes the works in progress for the ticket-links branch, targeted at solving #31 and #886 (well, #9550).

A more formal proposal will be developed in parallel, in TracDev/Proposals/TicketLinks.

Queries

So far, all "multi-valued" fields for a ticket were simple text columns with white-space or comma separated content (keywords, CC). This is of course not proper "relational" design, but was enough for our needs (notwithstanding #918). It was convenient as well, as in a query we could retrieve all the values at once, as they were in a single row, from the same ticket table or from the ticket_custom table in case this was for a custom field.

Now, we have a secondary table ticket_links with potentially multiple rows per ticket, and we can't directly retrieve the values in the same single query, as this would retrieve multiple rows per ticket, with lots of duplicate content, the values for the ticket and ticket_custom columns (see [e43ec53b481d/ticket-links]).

To solve this, we can experiment with group_concat approach, but this seems non-portable and looks like a hack… The other possibility is to make secondary requests in order to retrieve the linked values from the ticket_links table. This approach sounds promising as we could extend it to handle #918, and is in line with the ideas developed in GenericTrac.

This could indeed be extended to the normal fields as well, as we could then limit the amount of data retrieved in the initial query to the ticket ids, count them and only retrieve the actual ticket data for the tickets we need, i.e. those which are viewable and in the current page (#7608).
End of parenthesis.

Other Issues

• Ticket.delete_change is not yet supported (reuse Update links logic from Ticket.save_changes
• only store relations in one direction, and make use of the implicit reverse relation
• more metadata for link types:
  • is the relation "blocking"? links like "depends" or "blocks", and "children" are all blocking: the source ticket can't be closed until all the destination tickets are themselves closed
• specialized link renderers (see also FieldRefactoring)
  • we could even think about having specialized queries depending on the fields, like showing all the duplicates by getting the transitive closure of the duplicate-of link
  • state of "children" tickets could be shown using a progress bar (corresponding query would be parent=<this-ticket-id>) (#9550)