Open cmsd2 opened 7 years ago
This is a good point for a brainstorming on our table structure. Since DynamoDB doesn't allow querying on nested items we probably have to keep things we want to query on top level. The best solution I came with is what you see now. If you have any ideas or starting points on how this can be solved - please share!
Having these claims as top-level stringsets is nice in that it allows conditional updates/deletes and update expressions that operate directly on the sets. It also allows filter expressions in queries/scans.
The alternative is to force users of the tables to fetch entire records and manipulate or filter in memory.
I'm thinking this might not be such a loss:
The table GSIs are all high cardinality so I think that it's unlikely to be a problem for queries: queries will already be very selective so filtering in memory might not be a problem.
Updates and deletes would need to rely on the optimistic locking instead of conditional expressions and updates need to replace instead of mutate.
Scans would end up returning all rows. It's a shame, but how about using streams, or loading the table into redshift instead.
both users and roles have the same pattern for storing claims, and they both require that the claim types and the claim values are a set of unique items (dynamodb does not allow inserting duplicates into a string set).
I think this is too restrictive and it denies legitimate uses of claims: e.g. http://benfoster.io/blog/asp-net-identity-role-claims
https://docs.microsoft.com/en-us/aspnet/core/security/authorization/claims f.t.a: "An identity can contain multiple claims with multiple values and can contain multiple claims of the same type."