- Status New
- Percent Complete
- Task Type Bug Report
- Category Backend/Core
- Assigned To No-one
- Operating System All
- Severity Medium
- Priority Very Low
- Reported Version 1.0 devel (github master)
- Due in Version Undecided
-
Due Date
Undecided
- Votes
- Private
Attached to Project: Flyspray - The bug killer!
Opened by peterdd - 09.03.2015
Last edited by peterdd - 13.08.2015
Opened by peterdd - 09.03.2015
Last edited by peterdd - 13.08.2015
FS#1960 - foreign key relations between versions and tasks
It seem that when deleting a version entry in a project, that tasks that have this version assigned are still connected to this deleted version. For example FS#1222 (on 2015-03-09).
There are several options to solve such things:
- Deny deletion of version as long as tasks assigned to this project version.
- Either by doing a testing SQL query to check this case coded in PHP. Take care to keep this centralized, must also be respected by an eventually later added Flyspray API (XMLRPC or whatever).
- add SQL foreign key constraints with ON DELETE RESTRICT
- Pro: some business logic can be directly enforced by SQL.
- Cons: higher requirements for hosting, if using mysql innodb tables must be available on the hosting
- Move the tasks of this version to a default fallback version before deleting the version tag.
- Either doing one transaction doing : 1. move the tasks to its fallback version, 2. delete the version
- add SQL foreing key constraint with ON DELETE SET $fallbackversionid. Some pros & cons like on the the denying option.
The same for other assignments for tasks.
This issue is similiar to the massop issue: (https://github.com/Flyspray/flyspray/issues/130)
About a possible realisation with foreign key constraints
Little Update:
xmlschema03 may support this by using the "platform" parameter for explicit setting the engine innodb for mysql.
introducing foreign key constraints would be a quite huge refactoring of the flyspray code, so not FS1.1 orf FS1.2.