[CSHARP-2747] Use Either monad to back KMSProviders Created: 20/Sep/19 Updated: 23/Sep/19 Resolved: 23/Sep/19 |
|
| Status: | Closed |
| Project: | C# Driver |
| Component/s: | Field Level Encryption |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Vincent Kam (Inactive) | Assignee: | Unassigned |
| Resolution: | Won't Do | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Description |
|
Currently our KMS providers are backed with a IReadOnlyDictionary<string, IReadOnlyDictionary<string, object>> We use the following method to ensure that the values in the subdictionaries are strings or byte arrays.
We could make this restriction more explicit by using the Either monadto back the KMS providers internally: IReadOnlyDictionary<string, IReadOnlyDictionary<string, Either<string, byte[]>> |
| Comments |
| Comment by Robert Stam [ 22/Sep/19 ] |
|
Perhaps... but I'm not sure that it's worth it. I see at least two problems with `Either` (aside from the fact that it doesn't take the key into account):
I'd be interested in having you provide some sample code to understand better how this would look, but if it's restricted to two types only it seems like a dead end. Another point to consider is that the type of the `kmsProviders` parameter is defined in the spec, and using `Either` would be a deviation from the spec (perhaps justified, but a deviation nonetheless). |
| Comment by Vincent Kam (Inactive) [ 22/Sep/19 ] |
|
Hm it is true that the type depends on the key on which key that we're talking about. In the long run, perhaps a better type could be created. Currently though, wouldn't the use of `Either` make the current restriction that we've defined in `EnsureKmsProvidersAreValid` more explicit? |
| Comment by Robert Stam [ 21/Sep/19 ] |
|
That's probably not correct. Whether string is valid or byte[] is valid actually depends on which key we are talking about. And there could easily be other valid types in the future (boo}}l, {{int, etc...). |