JPA Map Storage: Single-use Object IDs vs UUID

[sguilhen]

When implementing the JPA Map Storage for single-use objects, I came across an issue with the MapSingleUseObjectEntity id. Different services use different formats for their object keys, which are used as ids when interacting with the MapSingleUseObjectProvider.

For example, OAuth2DeviceCodeModel produces a key with the format dc. + deviceCode. OAuth2DeviceUserCodeModel, on the other hand, produces a key that equals realmId + .uc. + userCode. Other places, like the ParEndpoint, generate a UUID key.

These keys are taken by the MapSingleUseObjectProvider and used as the entity's id. So, when get(String key) is called, it retrieves the entity by this key by calling tx.read(key), which in JPA means this key is to be considered the entity's primary key. As this key can't be pinned to a specific format, we can't have a JPA entity with an Id column of type UUID, so in the initial PR I've used String instead for the Id column.

The issue here is that this makes the JpaSingleUseObjectEntity different from all other entities we've implemented for the JPA Map storage, which all use UUID, so we lose consistency in how the entities ids are defined.

The alternative would be to have a different searchable field in MapSingleUseObjectEntity, called objectKey or something like that, and change the provider to not search by primary key, but rather use ModelCriteriaBuilder to search by this new field. The id would then be generated by the store as UUID.

I would like to get some opinions on this. Does it seem ok to have the Id for this entity as a String, or is consistency more important to the point where we add a new field just to be able to map the id to UUID like the other JPA entities? How would something like that impact the hotrody impl, for example?

[ahus1]

My two cents on this: it feels strange rely on the deviceCode to be unique across all realms, as it seems no realm will be part of the primary key here.

I'm surprised that those entities are not realm specific in the first place?!

[sguilhen]

Good point. According to our team discussion yesterday, here's the link to a new issue to make these entities realm-specific: #12462