| | 1 | = Ticket Links |
| | 2 | |
| | 3 | This describes the works in progress for the [repos:ticket-links] branch, targeted at solving #31 and #886 (well, #9550). |
| | 4 | |
| | 5 | A more formal proposal will be developed in parallel, in TracDev/Proposals/TicketLinks. |
| | 6 | |
| | 7 | == Queries |
| | 8 | |
| | 9 | 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. |
| | 10 | |
| | 11 | 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]). |
| | 12 | |
| | 13 | To solve this, we can experiment with `group_concat` approach, but this seems non-portable and looks like a hack... |
| | 14 | 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. |
| | 15 | //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. |
| | 16 | // |
| | 17 | |
| | 18 | == Other Issues |
| | 19 | - `Ticket.delete_change` is not yet supported |
| | 20 | (reuse //Update links// logic from `Ticket.save_changes` |
| | 21 | - only store relations in one direction, |
| | 22 | and make use of the implicit reverse relation |
| | 23 | - more metadata for link types: |
| | 24 | - is the relation "blocking"? |
| | 25 | links like "depends" or "blocks", and "children" are all blocking: |
| | 26 | the source ticket can't be closed until all the destination tickets |
| | 27 | are themselves closed |
| | 28 | - specialized link renderers (see also FieldRefactoring) |
| | 29 | - we could even think about having specialized queries depending on the fields, |
| | 30 | like showing //all// the duplicates by getting the transitive closure of the |
| | 31 | ''duplicate-of'' link |
| | 32 | - state of "children" tickets could be shown using a progress bar |
| | 33 | (corresponding query would be `parent=<this-ticket-id>`) (#9550) |
