You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Migrations of procedures/functions are not done as delta migrations, but as a drop & create (replace) statements. For this reason, it's really hard to track the changes - since there are many "copies" of the function and git diff doesn't visualize the different between these coppies.
I propose introducing support for a file, which may be modified and would be deployed (executed) if the hash changes. The usage of this behaviour would have only one restriction - the procedure/function cannot be used in migration. (In such case, the migration would have to "copy" the "old" function to custom temporary function.)
The text was updated successfully, but these errors were encountered:
I agree with the problem, but not so much with the proposed solution. I think that better solution is to have a single directory where you store the procedures and a command which generates migrations if anything in the directory changes.
You can auto sync when calling continue, if the sync step is too annoying. The added value is that the core (both in sense of ideas and actual code) of migrations remains intact.
Migrations of procedures/functions are not done as delta migrations, but as a drop & create (replace) statements. For this reason, it's really hard to track the changes - since there are many "copies" of the function and git diff doesn't visualize the different between these coppies.
I propose introducing support for a file, which may be modified and would be deployed (executed) if the hash changes. The usage of this behaviour would have only one restriction - the procedure/function cannot be used in migration. (In such case, the migration would have to "copy" the "old" function to custom temporary function.)
The text was updated successfully, but these errors were encountered: