Page Comparison

...

Currently, each time we create a new CapabilitySet, we always create it from scratch and never update it. We resolve the capability ID by its name, and if we can't find it, we exclude it from the result and log a warning. If we can resolve at least one capability, we create the CapabilitySet in the system, and it appears to the end user.

private Optional<UUID> getCapabilityId(Map<String, UUID> existingCapabilityIdsMap, String capabilityName) {
  var value = existingCapabilityIdsMap.get(capabilityName);
  if (value == null) {
    log.warn("Capability id is not found by capability name: {}", capabilityName);
    return Optional.empty();
  }

  return Optional.of(value);
}

So, in this case, instead of creating a partially valid CapabilitySet or not creating it at all, we need to create a dummy CapabilitySet in a separate table with the following structure.

...

instead of ignoring this capability set, we will create it regardless of whether it partially includes some capabilities or lacks them entirely. However, all missing capabilities need to be recorded in the dummy capability ID mapping table so that we can resolve them in the future once they are created.

Image Added

Now we have all the necessary information to create update the capability set in the future, except for once the missing capability IDs that have not yet been createdis created in the system.

Next, we need to extend the logic to create new capabilities. Once a capability is created, we should update the capability ID for all entries that exist in the DummyCapabilityIdMapping.

...

which populates all capability IDs for the particular capabilityNext

Then, we need to check if any capabilitySet has all its missing capability IDs populated. If such a capabilitySet exists, we should create a real capabilitySet from the dummy data and then remove it from the dummy table.

SELECT d.capabilitysetid FROM DummyCapabilityIdMapping d GROUP BY d.capabilitysetid
having count(case when d.capabilityid IS NOT NULL then 1 end) = count(*)

The query below returns all dummy capability set IDs that need to be created as real capability sets. All necessary data already exists and can be retrieved from the dummy tables.

Then we need to perform a cascading delete on the dummy capability set table data.run the capability set update process for the capability sets affected by the creation of a new capability event.

After that, we need to remove the record from the dummy capability ID mapping table.

Statements

• We don't want to create a separate dummy capability set table since we will always create capability sets, regardless of whether they include all capabilities, only a partial set, or are empty.

• If a capability does not exist, we will create a record in the dummy capability ID mapping table to resolve the relationship in the future.

• Each time we create a new capability, we check the dummy capability ID mapping table to resolve any missing relations and run the update capability set method, which will create Keycloak resources and other necessary components.

• The process of updating the capability set should be event-driven and need to use Kafka events instead of Spring events. This approach will help maintain data consistency in case the service crashes.

• Delete the event and record in the dummy mapping table only when the capability set is fully updated

Conclusion

I would choose option 4, as it can be easily implemented for phase one and would cover all possible cases where capabilities may be defined in other applications.

...