Rework changes detection; Implement tests for renames #188
Conversation
When object has 'renamed_from' property, but the previous version does not exists, the warning should be issued and for this object CREATE XXX query should be generated.
Fixes: 185 GitHub: dbsrgits#185
KES777
force-pushed
the
implement_tests_for_renames
branch
from
0575de1 to
9ddf601
Compare
|
Also fixes this: jjn1056/DBIx-Class-Migration#129 |
KES777
force-pushed
the
implement_tests_for_renames
branch
from
63d26ac to
f9e50ba
Compare
Eg. SRC:x, DST:y:rx, DST:x
Renames should go first, otherwise it could not be possible to add a new column with the name which was just renamed to something. Eg. SRC:x->DST:y, Create DST:x. Otherwise we can not run 'Create DST:x', because schema still have 'x' column.
KES777
force-pushed
the
implement_tests_for_renames
branch
from
f9e50ba to
fd58e13
Compare
There was a problem hiding this comment.
the tests here have nothing to do with the rest of the producer behaviors, could you just put this in a new diff test which produces yaml?
There was a problem hiding this comment.
Btw it was done few month ago.
| # alter ( $src_version, $dst_version ) | ||
| # create( $dst_version ) | ||
| # drop ( $src_version ) | ||
| # next ( $dst_name, $dst_version ) |
There was a problem hiding this comment.
i'm not understanding what the next callback is meant to do; would you mind expounding on that?
There was a problem hiding this comment.
next call back is fired for every dst column. This is to run some code for each dst name/column/table.
At the moment this call back is used to prepare/initialize required data structures which will be filled/used later.
I agree that the name is not the best. Probably it could be better if we name it every or init. Just suggest better name you like and I'll change it.
|
Intention in this PR is to fix bugs, generalize code and extend tests. |
| # now add everything else | ||
| push @sql, batch_alter_table_statements( | ||
| $diff_hash, $options, qw( | ||
| rename_field |
There was a problem hiding this comment.
I assume that this change corresponds to the change at https://github.com/dbsrgits/sql-translator/pull/188/files#diff-d1a0629b4bf9c95c1131cc9eaadd08c23943af65ad4b679de4b8190ee019a87bR315-R317, but I don't see why there needs to be a reorder of these entries.
There was a problem hiding this comment.
@matthewpersico Thank you for doing review.
It is documented in the commit: 740fa22
Renames should go first, otherwise it could not be possible to add a new column with the name which was just renamed to something. Eg. SRC:x->DST:y, Create DST:x.
Otherwise we can not run 'Create DST:x', because schema still have 'x' column.
Compare:
SRC:x->DST:y, Create DST:x. This works because x was renamed, then we can create field x.
VS
Create DST:x, SRC:x->DST:y. This does not work. We can not create x because schema already has x. Though it will be renamed a few seconds later.
Almost the same logic as for the case when we should drop before add.
There was a problem hiding this comment.
The generated statements should be in the same order. Imagine if here
a column is not renamed to something else (1), then ADD COLUMN statement (2) will fail.
3 participants
In this PR we:
renamesworkflows.Now function could be easily reused for different types of objects
This happens when we want to drop the old object and give the name of dropped object to another one.
This changes are related to #184