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
0575de1 to
9ddf601
Compare
|
Also fixes this: jjn1056/DBIx-Class-Migration#129 |
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.
f9e50ba to
fd58e13
Compare
rabbiveesh
left a comment
There was a problem hiding this comment.
apologies on the slow turnaround; out of perl now and just started a new $job, but i'll see if i can squeeze this in.
Trying to understand the full intent + then i can dig into more
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.
There was a problem hiding this comment.
okay i finally got a full undestanding here;
here's my take re naming -
$changes gets renamed to actions, and all of its fields get a name prefixed with on_ b/c these are actions - so on_create, on_drop, on_rename and so on
the $is_renamed should be called $check_renamed cuz it sounds like a boolean rather than a callback
honestly, all 3 of those params can get put together under one hash called checks or something, and also have names that more clearly say that they're callbacks
i'm ready to approve once the naming changes are in and also the comments are adjusted (right now they're out of sync, code uses init and the comment says next)
|
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.
matthewpersico
left a comment
There was a problem hiding this comment.
So sorry this fell off the table.
| rename => sub{ | ||
| my( $src, $dst ) = @_; | ||
| if( $src ) { | ||
| push @{ $diff_hash->{fields_to_rename} }, [ $src, $dst ]; $skip = 1; |
There was a problem hiding this comment.
the $skip state tracking here is subtle and easy to misunderstand; i'd recommend something else:
in your engine above, you should have rename NOT fire alter also, and then the rename callback can itself call the alter callback in the table case.
what do you think about that?
rabbiveesh
left a comment
There was a problem hiding this comment.
I've settled on names, and then i have comments about the $skip bit in the table field diff
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