feat(db) move ssl_certificates from dao to db #3315
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Migrations
ssl_certificates
table renamed tocertificates
ssl_servers_names
table renamed toserver_names
. Added a new field (id
, UUID) and made that the PK. But also added indexes for thename
field.Admin API
/snis
is now/server_names
and is automatically generated by the new DAO admin api generator-from-schema./certificates
is also generated, but it has some overrides, to deal with three "special" things:server_names
accepts a comma-separated string or an array of strings. Itallows "setting the server names in one go" when creating (POST) or updating
(PATCH) a certificate.
server_names
attribute is automatically added to the certs when gettingeach one individually or when getting a list of them.
name
attribute ofany of its associated
server_name
s.PUT
is not allowed any more.DAO
ssl_certificates
and ssl_servers_names' schemas translated to new DAO's schemas (renamed tocertificates
andserver_names
).dao:delete*
methods. This read was needed in order to propagate the structure through the worker events so it could be deleted properly (worker events can use any attributefrom the entitity, for example for the server names you need their
name
attribute. So if you delete a server name using itsid
you still need to read it in order to propagate an event with thename
field).certificates
has a custom DAO to deal with theserver_names
pseudo-attribute and for "looking for a certificate using one of its server names'name
"server_names
also has a custom DAO for "using the server names as if they were lists of strings", which is easier to do than "handling them as instances of theserver_names
schema".Tests
DAO:delete*
methods now returns the entity which was erased instead oftrue
, so some tests had to be changed fromis_true
tois_truthy
.PUT
where just removedFuture work
PUT
ones). However, the auto-generated APIs include more endpoints which will also need to be tested. That will be done in a separate PR./server_names
endpoint is not needed any more (it's useful for counting the total number of server names in some tests, but that's all). I will also explore the possibility of not including this endpoint on the other PR.delete_by_field
methods on the strategies (we can use the PK, we have it because of the "read"). We could remove those methods.