-
Notifications
You must be signed in to change notification settings - Fork 204
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Profile: only initialise the repository during the migration
The new disk object store migration that will ship with `v2.0` requires to be initialised once and only once, and it will generate the necessary folders and configuration file. This process was being done in the method `Profile.get_repository` guarded by a check in case it was already initialised. The problem with this was that the container could be initialised too early during the early stages of a profile setup. As soon as the repository was fetched, it would be initialised generating, among other things, the UUID. This would then trigger the check that the database contained the same UUID, which would of course fail, since the database was empty. This could have been fixed by ignoring the check at this point, but the real problem is that the repository should not be initialised at this point. The only point at which the repo should be initialised is during the corresponding database migration that introduced the disk object store repository. Both for existing as well as for new profiles, they will go through this migration and so it and it alone should be responsible for initialising the repository. This approach did create problems for the unittests though, as they would sometimes clean the repository. It would this not by just removing the contents, but it would delete the entire container. This meant it had to be recreated, but since in normal operations this only happens during the migration (which also during tests only happens once, unless maybe during the migration tests themselves) and so an error would be raised that the repository is not initialised. The solution is to reinitialise a new repo as soon as the old one was destroyed. Currently this is done by simply deleting the folder on disk and reinitialising an entire new instance. In the future, it would be better if the existing container could be kept and its contents could simply be dropped, but this would require a feature in the `disk-objectstore` library.
- Loading branch information
Showing
5 changed files
with
32 additions
and
35 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters