Change Details

The indexers' model is stored in the main database softwareheritage. That's not that db's concern. We should split that in a separate db. As we do for other modules. This way, we : - are consistent with other modules (cf. archiver, vault, deposit, etc...). - share patterns of development Typically the need to update the content_archive table (archiver, T494) is the same for the content_mimetype (which is the indexer's starting point). As a short term good side effect, we could have a sustainable way to schedule the indexers (which is not so far T864). As a long term good side effect, we will increase the need for the journal to be deployed as it's one more brick that needs it.

The indexers' model is stored in the main database softwareheritage. That's not that db's concern. We should split that in a separate db. As we do for other modules. This way, we : - are consistent with other modules (cf. archiver, vault, deposit, etc...). - share patterns of development Typically the need to update the content_archive table (archiver, T494) is the same for the content_mimetype (which is the indexer's starting point). As a short term good side effect, we could have a sustainable way to schedule the indexers (which is not so far T864). As a long term good side effect, we will increase the need for the journal to be deployed as it's one more brick that needs it. Note that this implies that the indexer database won't be backup-ed any longer. It was implicitely so since the main db is backup-ed and replicated.

The indexers' model is stored in the main database softwareheritage. That's not that db's concern. We should split that in a separate db. As we do for other modules. This way, we : - are consistent with other modules (cf. archiver, vault, deposit, etc...). - share patterns of development Typically the need to update the content_archive table (archiver, T494) is the same for the content_mimetype (which is the indexer's starting point). As a short term good side effect, we could have a sustainable way to schedule the indexers (which is not so far T864). As a long term good side effect, we will increase the need for the journal to be deployed as it's one more brick that needs it. Note that this implies that the indexer database won't be backup-ed any longer. It was implicitely so since the main db is backup-ed and replicated.