Edgewall Software
Home
Trac
Trac Hacks
Genshi
Babel
Bitten
Home
Download
Documentation
Mailing Lists
License
FAQ
Search:
Login
Preferences
Help/Guide
About Trac
Wiki
Timeline
Roadmap
Browse Source
View Tickets
New Ticket
Search
Context Navigation
+0
Start Page
Index
History
Editing TicketLinks
Adjust edit area height:
8
12
16
20
24
28
32
36
40
Edit side-by-side
= Ticket Links This describes the works in progress for the [repos: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)
Note:
See
WikiFormatting
and
TracWiki
for help on editing wiki content.
Change information
Your email or username:
E-mail address and name can be saved in the
Preferences
Comment about this change (optional):
Note:
See
TracWiki
for help on using the wiki.