Repository navigation
Replies: 3 comments 1 reply
I believe it shouldn't ignore the additional fields. When new version of schema will need to be introduced, there'd be also be needed to add a migration step into particular So during reading (deserializing) json the object would be migrated to be usable in current version (and updated only when any write operaton is performed). |
|
@vramik - my previous note was incomplete and therefore wrong. Please let me add to my previous statement:
Therefore migrations won't help here, as they can handle N+1 versions. |
|
Summary of a discussion within the storage team: There is the additional requirement to do a rollback to a previous Keycloak version that also includes falling back on a previous storage version N after entities have been written with N+1 version. This then requires that a N version can write entities with a N+1 version. To do that consistently, it would then need to downgrade the entity version stored in the database as well. Being able to write the N version to the database puts restrictions on the kind of changes that could be made to the schema; it might require adding a new column and not using it for data that must not be lost by a rollback. Action items for @ahus1:
|
The original docs contained the following paragraph that I missed:
The PR above tries to elaborate on downgrades so a future me could see the implications this has. |
Uh oh!
There was an error while loading. Please reload this page.
Problem statement
The current JPA map storage implementation has one field entityVersion that identifies the schema version. This identifies (a) the format the JSON has been written in and (a) might show how and if some additional search columns/tables have been filled.
The JSON is migrated on read, and when the entity is updated the entity version is updated to the current entity version from the perspective of the now running Keycloak version. It also ensures that it only reads entity versions that are the current supported version +1; it will fail with a IllegalArgumentException on any higher version (see JpaEntityMigration).
This sums up as:
This could fail in the following way:
This could also fail in ways that a additional fields are not updated by the (N) Keycloak version what would need to be updated by a (N+1) entity version.
How to update an entity that has been written to the database with a (N+1) version is not handled in the concept document here: https://github.com/keycloak/keycloak-community/blob/main/design/keycloak.x/storage-persistence.md
Approach
Out of scope / future task: In a no-downtime scenario write access could be redirected only to the new versions of Keycloak (assuming a green-blue-deployment scenario).
Benefits
Alternatives
All reactions