diesel
diesel copied to clipboard
Add ability to serialize additional fields to the MigrationMetadata
We would like to attach additional fields to the MigrationMetadata
, to give us the ability to manage the migrations in a better fashion.
How we'll use it
Our tenants are separated in different schemas, but also there's a shared schema.
Normally we would set the scope for each tenant via search_path
before running migrations, and try to make the "shared" migrations idempotent, but that's annoyingly complicated and not flexible.
By allowing additional fields in the metadata, we would be able to extract a flag like is_shared
, and only run that in the "global" scope, not once for each tenant.
An alternative that we considered for that, would be splitting the two sets of migrations into different folders, and merging the two sets afterwards, but extending the metadata seemed cleaner.
Ah, I see the problem with const fn
. Will try to think how to best go around this, but any suggestions are of course welcome :)
I would prefer not adding any additional dependency to migration_internals
and not to use serde_json::Value
as "stringly" typed value type there.
That written: I can see use cases for such an API and I'm willing to accept a better designed version of this. I cannot say how that would look like and at least for me personally it's currently not a priority to design such an API.
Ok, that makes sense.
If I limited the scope from this implementation, and basically only allowed literal strings as the values (therefore not dealing with any further serde_json::Value
and similar things) would that be more acceptable? If string is still too relaxed for your liking, a further paring down that still serves my purpose would involve basically only allowing booleans, but hopefully we don't need to push it that far :)