Metadata fields on policies
devdavidkarlsson opened this issue · comments
Hi, I was thinking about adding some more fields to the policies. For example, I may want to trace the origins of a specific policy: when was the policy created, and who created it. What is your opinion about adding these fields?
Thanks
I am open to this. Let's discuss some ideas here! I think there are some standard ones such as:
- Owner (The owner/creator of the policy), could also be an array Owners
- CreatedAt - timestamp when policy was created
- UpdatedAt - timestamp when policy was updated
Yes, It is something along what I had in mind.
A question that comes to mind is the following:
- Would an owner be of any specific format, i.e. an owner is of a format similar to "subject"?
In case of "non-specific format" some limitations may necessary to the owner field, string length etc.
I imagine it being an indexable value (so something along the lines of varchar), so we can search it efficiently. If it's an array, we'd probably have do normalize it into it's own table policy_owner because MySQL doesn't support arrays afaik.
Hey,
has there been any progress towards the inclusion of metadata fields?
I have a situation where I need to track the tenant a policy belongs to and would like to be able to query by the tenant. I thought about storing additional metadata in redis, but ideally would like to avoid the complexity of an additional Datastore.
My idea would have been to add a 'meta' field to policies which can take arbitrary json objects.
Hi I have not been working anything on this. Been busy unfortunately.
Ok, no problem. I plan on tackling the problem, but I am unsure how an ideal solution would look like.
Besides storing the metadata I would like to query policies by it. What do you think of storing metadata as json objects (e.g. jsonb column in PostgreSQL) and exposing an additional Query Method on the Manager?
I don't like the idea of exposing a query interface, as it clearly depends on the underlying technology (e.g. PostgreSQL only) and it's quite hard to write a query interface as good as SQL or some common NoSQL interfaces. If there is however a generic solution to tackle this, I'm open to give it a try.
In my opinion, it would be better to provide the default implementation with a way to store metadata, and then simply extend your specific implementation with a method that performs your query.
Ok, I see that exposing a query interface in the default implementation does not make too much sense.
What do you think about storing metadata as arbitrary json?
Yeah that would be ok, for MySQL we should probably just use longtext or something
Why would you use a lontext over the native json data type that MySQL provides? Most of the time I work with Postgres, so I am not as familiar with MySQL
Because MySQL 5.5 and 5.6 do not support that datatype but are officially supported and used predominately.
Closing because this repository is being archived.