Importing data messes up related tasks #1556
Labels
No Label
dependencies
duplicate
help wanted
invalid
kind/bug
kind/feature
needs reproduction
question
security
wontfix
No Milestone
No Assignees
3 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: vikunja/vikunja#1556
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Description
Previously, I've run Vikunja with SQLite as backend. But as the performance couldn't keep up any more, I've switched to MySQL/MariaDB as backend. To transfer the existing data from SQLite to MariaDB, I exported and re-imported it.
After the re-import, all relationships between tasks were messed up. Say, for example, I had a task A which had a task relation of "subtask" with task B. After the re-import, task A still had a task relation, but it pointed to task X instead.
If I had to guess, I'd say that the tasks get probably "renumbered" during the import, meaning they get assigned new internal ids. But the foreign keys for task relations probably don't get adjusted accordingly.
Vikunja Frontend Version
dev (build it myself to get it run in a subdirectory)
Vikunja API Version
0.20.4
Browser and version
No response
Can you reproduce the bug on the Vikunja demo site?
No
Screenshots
No response
Can you check the task relations table between the sqlite version and the mysql version?
@xeruf did you notice the same when you migrated to postgres?
I've created a little test: In the old sqlite db, I've created a "Task A", that refers to a "Task B" as its successor. The ids in the
tasks
table areThe relationship seems to be correct in the
task_relations
tableThen I've exported this and re-imported it into a newly created test database in MariaDB. Now, "Task A" and "Task B" got new ids
In the new
task_relations
table, things get... interestingIn the frontend, I see a relationship to a completely different task. I remember that different task having multiple relationships prior to the migration, but not to "Task A" or "Task B".
That's interesting, because the restore process leaves all ids as they were in the old db. Can you check the values of the
tasks.json
andtask_relations.json
files in the export for both tasks?I don't think I had really used relations before migrating, so I can't help here
Is this still a problem? I've just checked with the latest unstable build and it seems to work fine.