| 78 | | So the new model could be simply: |
| | 78 | The second style (prop/value) can be implemented in several ways: |
| | 79 | - a single `properties` table with `prop` and `value` string columns (this is what our current `ticket_custom`, `system` and `repository` tables do) |
| | 80 | - a single `properties` table with `prop` and several typed columns (`int_value`, `string_value`, `date_value`, etc.), only the appropriate column being used - see discussion [#JBPM-approach below] |
| | 81 | - several `properties` tables with each `prop` and `value` columns, each table dedicated to a given type (`int_properties`, `string_properties`, etc.) |
| | 82 | - ... more ... |
| | 83 | |
| | 84 | |
| | 85 | So for example the new model could be simply: |
| 424 | | '''Comments''' (cklein) |
| 425 | | - Why not implement all of the different `resource_prop*` tables into a single table, where each tupel has multiple attributes, see for example the JBPM datamodel for a working and presumably also fast approach. Here, there exists a process_variable or some similar table that stores all the different value types in single table. |
| | 431 | == Possible Implementation Plan == |
| | 432 | |
| | 433 | === Milestone First === |
| | 434 | - modify the Milestone module so that it uses the new proposed datamodel. |
| | 435 | - experiment new tabbed view for the milestone (''View'', ''Discussion'', ''History''). See TracProject/UiGuidelines. |
| | 436 | - milestone should be able to have attachments, too (#3068) |
| | 437 | - adapt the Roadmap module to the new model |
| | 438 | - adapt the Milestone admin component to the new model |
| | 439 | |
| | 440 | Once this is complete, validate the genericity by promoting the components to be first class resources as well (#1233). |
| | 441 | |
| | 442 | === Ticket First === |
| | 443 | |
| | 444 | As the ticket module is by far the most complex, it might be worth to |
| | 445 | try out the new model there first: |
| | 446 | - we could verify that we meet the expectations in terms of code simplification, |
| | 447 | solving open issues, etc. |
| | 448 | - we could detect early if there are no regressions or risk of losing current features |
| | 449 | - by redeploying the ticket infrastructure to the other components, |
| | 450 | we could spread the most benefits of tickets (comments, |
| | 451 | custom fields, queries, etc.) to other resources (milestone, wiki, component, ...) |
| | 452 | |
| | 453 | === Wiki First === |
| | 454 | |
| | 455 | Milestone and components are closer in spirit to a wiki page than to a ticket (we have the long standing #3776 ticket). |
| | 456 | |
| | 457 | We could as well start simply on the wiki model and wiki module, to rework the basics there, and once this is done port the changes to the milestone module, then work on the components. |
| | 458 | |
| | 459 | If we do this, we can also at the same time think about the storage model, in particular how past versions could be stored in a VCS (#1132). We could then think about a serialization model that would play nicely with the genericity of the Trac resources on one hand side, and with the external editors on the other hand. |
| | 460 | |
| | 461 | == Related Tickets == |
| | 462 | |
| | 463 | - Data model issues: [[TicketQuery(status=!closed&keywords=~model)]] |
| | 464 | - Resource related: [[TicketQuery(status=!closed&keywords=~tracobject)]] |
| | 465 | |
| | 466 | |
| | 467 | |
| | 468 | == Discussion |
| | 469 | |
| | 470 | - (cklein) [=#JBPM-approach] Why not implement all of the different `resource_prop*` tables into a single table, where each tuple has multiple attributes, see for example the JBPM datamodel for a working and presumably also fast approach. Here, there exists a process_variable or some similar table that stores all the different value types in single table. |
| 487 | | == Possible Implementation Plan == |
| 488 | | |
| 489 | | === Milestone First === |
| 490 | | - modify the Milestone module so that it uses the new proposed datamodel. |
| 491 | | - experiment new tabbed view for the milestone (''View'', ''Discussion'', ''History''). See TracProject/UiGuidelines. |
| 492 | | - milestone should be able to have attachments, too (#3068) |
| 493 | | - adapt the Roadmap module to the new model |
| 494 | | - adapt the Milestone admin component to the new model |
| 495 | | |
| 496 | | Once this is complete, validate the genericity by promoting the components to be first class resources as well (#1233). |
| 497 | | |
| 498 | | === Ticket First === |
| 499 | | |
| 500 | | As the ticket module is by far the most complex, it might be worth to |
| 501 | | try out the new model there first: |
| 502 | | - we could verify that we meet the expectations in terms of code simplification, |
| 503 | | solving open issues, etc. |
| 504 | | - we could detect early if there are no regressions or risk of losing current features |
| 505 | | - by redeploying the ticket infrastructure to the other components, |
| 506 | | we could spread the most benefits of tickets (comments, |
| 507 | | custom fields, queries, etc.) to other resources (milestone, wiki, component, ...) |
| 508 | | |
| 509 | | === Wiki First === |
| 510 | | |
| 511 | | Milestone and components are closer in spirit to a wiki page than to a ticket (we have the long standing #3776 ticket). |
| 512 | | |
| 513 | | We could as well start simply on the wiki model and wiki module, to rework the basics there, and once this is done port the changes to the milestone module, then work on the components. |
| 514 | | |
| 515 | | If we do this, we can also at the same time think about the storage model, in particular how past versions could be stored in a VCS (#1132). We could then think about a serialization model that would play nicely with the genericity of the Trac resources on one hand side, and with the external editors on the other hand. |
| 516 | | |
| 517 | | == Related Tickets == |
| 518 | | |
| 519 | | - Data model issues: [[TicketQuery(status=!closed&keywords=~model)]] |
| 520 | | - Resource related: [[TicketQuery(status=!closed&keywords=~tracobject)]] |
| 521 | | |
