A more formal proposal will be developed in parallel, in TracDev/Proposals/TicketLinks.
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_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.
Ticket.delete_changeis not yet supported (reuse Update links logic from
- 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