Add synthetic UNIQUE constraint to retention policy table #28
Conversation
| selectable = sa.select(table).where( | ||
| table.c.table_schema == policy.table_schema, | ||
| table.c.table_name == policy.table_name, | ||
| ) |
There was a problem hiding this comment.
It can make sense to have multiple policies for one table. Especially to combine the reallocate strategy with others.
Example: For table x, I want to reallocate partitions after 30 days from a hot to a warm node, and after 60 days I want to permanently delete it (or snapshot with deletion).
But indeed it doesn't make sense to have a combination of the snapshot + delete strategies on the same table, as both will erase the data.
A reallocate strategy with a shorter retention period than a delete/snapshot strategy makes sense, though.
There was a problem hiding this comment.
Hi Niklas.
I was having roughly about the same thoughts, so I am happy you are referring to a specific example.
Maybe we can track the new insights at GH-26, in order to come up with a better plan how to handle the constraints more specifically? It looks like we need to come up with specific rules here instead of implementing uniqueness constraints in a generic manner.
In this way, we can proceed with integrating all the stacked PRs, and iterate on this topic later once more.
WIth kind regards,
Andreas.
There was a problem hiding this comment.
Sounds good, let's save it for another iteration 👍
amotl
force-pushed
the
amo/datamodel-uniqueness
branch
from
ce5b2e6
to
a3cefad
Compare
About