Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

#

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

Jump to bottom

Bug: Migration Script doesn’t set Relationship versions #74

Closed
JeremyCaney opened this issue Mar 30, 2021 · 2 comments
Closed

Bug: Migration Script doesn’t set Relationship versions #74

JeremyCaney opened this issue Mar 30, 2021 · 2 comments
Assignees
@JeremyCaney
Labels
Area: SQL Relates to the SQL Server database objects; do not use for the repository. Priority: 1 Severity 2: Major Status 3: In Progress Currently being worked on. Status 5: Complete Task is considered complete, and ready for deployment. Type: Bug Behavior that is inconsistent with documented or expected behavior.
Milestone
OnTopic 5.1.0

Comments

@JeremyCaney
Copy link
Member

With OnTopic 5.0.0, we introduced versioning for Relationships. When the migration runs, the Version for each relationship is set to the GETUTCDATE() of the migration. Similar to #70, however, this means that a Rollback() to prior to the OnTopic 5.0.0 migration date will result in relationships being deleted. Unlike #70, however, we don't have historical data as to when each relationship was introduced.

Solution

To mitigate this, the migration script should set the Version of each relationship to the first version of the Source_TopicID, thus ensuring that any version that is rolled back to will maintain the pre-migration relationships.

Limitations

It's worth noting that this won't make any effort to determine whether the Target_TopicID existed at that point. A slightly smarter version might take the earliest version of the Source_TopicID or Target_TopicID, and use the latest of those two versions. In practice, however, this won't be an issue since rolling back a topic only affects the current version, and the Target_TopicID will always exist in the database. (If it's deleted, the source relationship will also be deleted with it.) Regardless, this remains consistent with how rollbacks worked prior to OnTopic 5.0.0.
@JeremyCaney JeremyCaney added Type: Bug Behavior that is inconsistent with documented or expected behavior. Area: Repositories Relates to the `ITopicRepository` interface or one of its implementations. Severity 2: Major Priority: 1 Status 3: In Progress Currently being worked on. labels Mar 30, 2021
@JeremyCaney JeremyCaney added this to the OnTopic 5.1.0 milestone Mar 30, 2021
@JeremyCaney JeremyCaney self-assigned this Mar 30, 2021
@JeremyCaney
Copy link
Member Author

We will need to use ExtendedAttributes to determine the earliest version because the first version of a Topic will always have an ExtendedAttributes record, even if it's empty. By contrast—with the migration of Key, ContentType, and ParentID to the Topics table—it isn't guaranteed that the first version of a Topic will have a corresponding Attributes record.

JeremyCaney added a commit that referenced this issue Mar 30, 2021
@JeremyCaney
Include Version in Relationships migration
2ec30da 
Sets the `Version` for `Relationships` to the earliest known version of the `Source_TopicID`. This accounts for the fact that versioning is new as of OnTopic 5.0.0, and we don't have historical version data; as a result, if a `Topic` is rolled back to a version prior to the OnTopic 5.0.0 migration, we want to make sure that the historical `Relationships` aren't deleted. This addresses #74.

For this, we used `ExtendedAttributes` because the first version of a `Topic` will _always_ have an `ExtendedAttributes` record, even if it's empty. By contrast, with the migration of `Key`, `ContentType`, and `ParentID` to the `Topics` table, it isn't guaranteed that the first version of a `Topic` will have a corresponding `Attributes` record.

Customers that have already migrated to OnTopic 5.0.0 will need to manually migrate these and then remove duplicates. Fortunately, this only applies to a couple of migrations, and should be easy. (Other current implementations are new, and don't have this issue.)
JeremyCaney added a commit that referenced this issue Mar 30, 2021
@JeremyCaney
Merge branch 'bugfix/association-versioning' into develop
3552bf6 
There were a number of bugs in how association versioning—i.e., versioning of `TopicReferences` and `Relationships`—was addressed as part of the migration and utility scripts, which this update resolves.

This includes:
- Setting the `Version` as part of the `TopicReferences` migration (#70, d041eae)
- Setting the `Version` as part of the `Relationships` migration (#74, 2ec30da)
- Consolidating the `TopicReferences` as part of `ConsolidateVersions` (#75, 7e322c0)
- Consolidating the `Relationships` as part of `ConsolidateVersions` (#75, b8c5d09)
@JeremyCaney JeremyCaney added the Status 5: Complete Task is considered complete, and ready for deployment. label Mar 30, 2021
@JeremyCaney
Copy link
Member Author

The Version on Relationships is now set as part of the migration script, as per 2ec30da.

@JeremyCaney JeremyCaney added Area: SQL Relates to the SQL Server database objects; do not use for the repository. and removed Area: Repositories Relates to the `ITopicRepository` interface or one of its implementations. labels Apr 3, 2021
@JeremyCaney JeremyCaney mentioned this issue Apr 7, 2021
Merged
# for free to join this conversation on GitHub. Already have an account? # to comment
Assignees

@JeremyCaney JeremyCaney

Labels
Area: SQL Relates to the SQL Server database objects; do not use for the repository. Priority: 1 Severity 2: Major Status 3: In Progress Currently being worked on. Status 5: Complete Task is considered complete, and ready for deployment. Type: Bug Behavior that is inconsistent with documented or expected behavior.
Projects
None yet
Milestone
OnTopic 5.1.0
Development

No branches or pull requests
1 participant
@JeremyCaney