Details
-
Improvement
-
Status: Resolved
-
Critical
-
Resolution: Fixed
-
None
-
None
Description
We currently only have one collection pr. installation. As the number of curator collections (CCs) may be quite large, 50+, a simple model with one CC pr. bit repository collection will lead to 50+ installations with 2++ pillar installations + a tomcat with 5 webservices each. A possibility for reducing the number of BR component instances is to store more CC in each BR. This has a number of drawbacks though:
- It will a nontrivial task to perform massprocessing on a CC. Has the pillar has no concept of a CC, this natural scope can be modeled by the pillar itself.
- Migration of a CC will be fragile has the BR isn't able to provide a list of files for a CC. This means the responsability for handling this has been moved external to the BR.
- Changing the preservation setup for a CC will include a full migration. If the pillars understood the concept of CC's the change would be a more simple reconfiguration of which preservation contect, the collection belonged to.
So a new option of having multiple collections in a single BR installation would adresse the listed problems, a still make it possible to reduce the number of installation significantly.
As the protocol already includes a collection ID for each message, this improvement would require changing the CollectionID in the collectionSettings to to being a list of ID's. The components involved in a Bit repository should then also be able to handle collectionID specific functionality.