Fix: Swapped IDs in parent_tags DB table

[HeikoWasTaken]

Summary

Stops child/parent tag IDs from being assigned to incorrect fields in the ts_library.sqlite db's tag_parents table as described in #997.

Tasks Completed

• Platforms Tested:
  • Windows x86
  • Windows ARM
  • macOS x86
  • macOS ARM
  • Linux x86
  • Linux ARM
• Tested For:
  • Basic functionality
  • PyInstaller executable

[Computerdores]

Good fix, but for this to be merged a migration for existing libraries would be needed (tests would be nice too).

@CyanVoxel I could have sworn to have reviewed or written a fix for this at some point, do you remember anything regarding that?

[CyanVoxel]

Good fix, but for this to be merged a migration for existing libraries would be needed (tests would be nice too).

@CyanVoxel I could have sworn to have reviewed or written a fix for this at some point, do you remember anything regarding that?

There were several issues with swapped parent/child/"subtag" language during the migration to 9.5, this may have slipped by during those changes. I'm also not sure if just swapping the assignment will have the intended effect or if there needs to be additional logic changes reflected, though testing will either confirm or deny that

[HeikoWasTaken]

Good fix, but for this to be merged a migration for existing libraries would be needed (tests would be nice too).

@CyanVoxel I could have sworn to have reviewed or written a fix for this at some point, do you remember anything regarding that?

Sorry if I'm talking over things that have already been discussed, I couldn't find anything related to this.

For the migration, I believe checking whether the Archived and Meta Tag tags are incorrectly set as parent/child should be enough to catch libraries that were created after this bug was introduced. But I'm not sure about older libraries which may have a mix of correct and incorrect parent/child relationships.

How would valid joins be differentiated from the swapped ones?

[Computerdores]

Good fix, but for this to be merged a migration for existing libraries would be needed (tests would be nice too).
@CyanVoxel I could have sworn to have reviewed or written a fix for this at some point, do you remember anything regarding that?

Sorry if I'm talking over things that have already been discussed, I couldn't find anything related to this.

All good, I was just under the impression that this had already been fixed, but apparently not.

For the migration, I believe checking whether the Archived and Meta Tag tags are incorrectly set as parent/child should be enough to catch libraries that were created after this bug was introduced. But I'm not sure about older libraries which may have a mix of correct and incorrect parent/child relationships.

How would valid joins be differentiated from the swapped ones?

Generally, I would suggest you increment LibraryPrefs.DB_VERSION and then add another migration similar to the existing ones.

[HeikoWasTaken]

Generally, I would suggest you increment LibraryPrefs.DB_VERSION and then add another migration similar to the existing ones.

Thanks, I'm not very familiar with the codebase so that's a big help. Will take a crack at it.

[HeikoWasTaken]

I was initially concerned about such a case:

1. Library is created prior to bugged version
2. Some tags are parented to other tags (correctly)
3. Library is updated to bugged version
4. More tags are parented to other tags (incorrectly)

Wherein the database would contain a mixture of correctly parented tags as well as incorrect ones, with no clear way of telling them apart.

However after some digging, it seems like this bug has been around since the first implementation of the tag_parents table, meaning that all records in tag_parents can be considered incorrect, and safely swapped back around without worring about false-positives (phew).

Just leaving this here for clarity.

[Computerdores]

Wherein the database would contain a mixture of correctly parented tags as well as incorrect ones, with no clear way of telling them apart.

In that case there would be no way to tell the correct and incorrect ones apart anyway so no need to worry about that on your end either way 😄

[HeikoWasTaken]

Just need to write some tests now, then should be ready for review

[HeikoWasTaken]

How are the test database fixtures in here created? Just blanks made by that specific version of tagstudio? Or is there some sort of tooling/procedure required to properly generate them?

[Computerdores]

How are the test database fixtures in here created? Just blanks made by that specific version of tagstudio? Or is there some sort of tooling/procedure required to properly generate them?

Not quite sure, @CyanVoxel would know best.
That said, I believe they were just created using some version of TS and then maybe modified in an external tool in some cases.