Closed mwhicks1 closed 3 months ago
Working with tags remains challenging for my project—we currently create entities that have the property tags: Set<String>
, and artificially remap tags into strings of form key: value
. We can then write policies like resource.tags.contains("label: foo")
. This works out ok, but feels a bit clunky and forces us to rewrite :
s in key names (to -
).
My project would be improved with this RFC if it's possible to implement.
I've dropped a new RFC that proposes entity tags. I believe it properly responds to @emina 's concerns while still satisfying the motivating use-cases. Please shift your attention to that one.
Working with tags remains challenging for my project—we currently create entities that have the property
tags: Set<String>
, and artificially remap tags into strings of formkey: value
. We can then write policies likeresource.tags.contains("label: foo")
. This works out ok, but feels a bit clunky and forces us to rewrite:
s in key names (to-
).My project would be improved with this RFC if it's possible to implement.
@jszmajda I've dropped a new RFC that proposes entity tags. I believe it properly responds to @emina 's concerns while still satisfying the motivating use-cases. Does it still work for your project?
Proposes to extend syntax of schemas, and validation, to support open records, which are useful for implementing simple maps from string to values.
Rendered
EDIT: Please shift your attention to a new RFC that proposes entity tags. It maximizes the benefits of this RFC (and adds some additional ones) while losing the drawbacks.