Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add ability to serialize additional fields to the MigrationMetadata #3332

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

to266
Copy link

@to266 to266 commented Sep 21, 2022

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.

@to266
Copy link
Author

to266 commented Sep 21, 2022

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 :)

@weiznich
Copy link
Member

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.

@to266
Copy link
Author

to266 commented Sep 26, 2022

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 :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants