Restoring Store-based access in migration code

[sae-bom]

While reviewing the migration code, I noticed that the current implementation accesses the database directly via a path, instead of using the previously existing Store abstraction. (from this commit)

From a code perspective, this change has a few notable implications:

• The migration logic no longer benefits from the common helper functions provided by Store.
• Backup-related functionality that was encapsulated in Store is no longer applied during migration.
• Some test code still appears to assume the presence of the earlier abstraction, which suggests partial coupling to the old design.

Given that the Store abstraction previously centralized database access and related concerns, it may be worth considering whether restoring the Store-based approach in migration code would be a better default, unless there is a clear reason to avoid it.

I’d like to ask for input on whether reverting this part of the migration logic back to using Store makes sense, or if the current direct-access approach is intentional and preferable going forward.

Any guidance on the intended direction would be appreciated.

[sae-bom]

@sophie-cluml
I’d appreciate your input on this.

Do you think this discussion is significant enough to move forward as a dedicated issue?
If so, should it take precedence over the existing issue #663? (Since this issue is also making changes to the migration code)

[sophie-cluml]

Based on the commit message in ddbea3f
, I believe the reason for accessing the DB directly via a path appears to be to support dropping the account_policy column family. Since the migration currently supports migration from version 0.43.0, it seems difficult to reverting this choice at the moment For that reason, reverting to a Store-based approach right now may not be feasible.

[sae-bom]

Based on the verbal discussion, we agreed to keep direct path-based access only for special cases where drop_cf or similar operations are required, while using the Store abstraction for general cases, following the approach used in earlier versions of the migration code.