Manual migrations
Menzorg opened this issue · comments
Hello. I spended some time to understad all what i need to do manual migration (env POSTGRES_MIGRATIONS=0). To my mind it is useful information for all who wants to use hasura-storage migrations as part of custom project migrations, and it could be in readme. Manual migration has stages:
- Creating schema and extensions
- hasura-storage/migrations/postgres/*.up.sql
- hasura metadata api track_table (files, buckets)
- hasura metadata set_table_customization (custom_name, custom_root_fields, custom_column_names)
- hasura metadata create relationships (object files.bucket_id -> bucket.id, array buckets.id => files.bucket_id[])
- hasura metadata create permissions (select, IUD)
If I had this list, I would save a day or two. But maybe it can be useful for community after all =) Maybe expand "Self-hosting the service" description?
What is your use case for manual migrations? Ideally NOBODY would have to disable migrations so I'd rather try to tackle that. It is certainly not a supported/recommended case and something that has the opportunity to add more headaches than anything else (hence why it is not documented, it is just available for very advanced users).
Manual migration has stages
I am a bit hesitant to document this in detail but we could add a note pointing to the current code that performs the migrations, just sending people to the right place.
Maybe expand "Self-hosting the service" description?
I wouldn't add it under "self-hosting" as this is not really a requirement and that might confuse people.
In any event, I'd like to hear your use case first :)
My case is project, that has own migration system. It is good, when migrating data controlled by one source, but if we will have many sources it will be hard to maintain and develop. So, when we add new lib to our project (hasura-storage), and this lib need to do something with data or data-store (pg), it is good idea to add new migration, which will add all it need, so process of project life will continue without artifacts. This migration controls changes, and fix current version of hasura-storage, so, when we will need to update -> it will be new migration in our project.
So, idea of this issue - if some project, like ours can have own migrating system, most likely developers want to create their own migration, and then -> they will want to understad what need to do.
Ok, I think I understand, we can add a note as suggested, something vague though, just to point in the right direction. I'd prefer if this was reserved to very advanced users that can look at the code and understand what's going on or this has the potential to become a mess for maintainers.
Cool, to my mind it will be great
Something like ATTENTION! ONLY FOR ADVANCED CHOSEN ONES =)
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.