view release on metacpan or  search on metacpan

lib/sqitchtutorial-vertica.pod  view on Meta::CPAN

L<PITA|https://www.urbandictionary.com/define.php?term=pita>. You have to make
changes like these:

=over

=item 1.

Copy F<deploy/userflips.sql> to F<deploy/userflips_twitter.sql>.

=item 2.

Edit F<deploy/userflips_twitter.sql> to drop and re-create the view with the
C<twitter> column to the view.

=item 3.

Copy F<deploy/userflips.sql> to F<revert/userflips_twitter.sql>.
Yes, copy the original change script to the new revert change.

=item 4.

Add a C<DROP VIEW> statement to F<revert/userflips_twitter.sql>.

=item 5.

Copy F<verify/userflips.sql> to F<verify/userflips_twitter.sql>.

=item 6.

Modify F<verify/userflips_twitter.sql> to include a check for the C<twitter>
column.

=item 7.

Test the changes to make sure you can deploy and revert the
C<userflips_twitter> change.

=back

But you can have Sqitch do most of the work for you. The only requirement is
that a tag appear between the two instances of a change we want to modify. In
general, you're going to make a change like this after a release, which you've
tagged anyway, right? Well we have, with C<@v1.0.0-dev2> added in the previous
section. With that, we can let Sqitch do most of the hard work for us, thanks
to the L<C<rework>|sqitch-rework> command, which is similar to
L<C<add>|sqitch-add>:

  > sqitch rework userflips -n 'Adds userflips.twitter.'
  Added "userflips [userflips@v1.0.0-dev2]" to sqitch.plan.
  Modify these files as appropriate:
	* deploy/userflips.sql
	* revert/userflips.sql
	* verify/userflips.sql

Oh, so we can edit those files in place. Nice! How does Sqitch do it? Well, in
point of fact, it has copied the files to stand in for the previous instance
of the C<userflips> change, which we can see via C<git status>:

  > git status
  # On branch main
  # Changed but not updated:
  #   (use "git add <file>..." to update what will be committed)
  #   (use "git checkout -- <file>..." to discard changes in working directory)
  #
  #	modified:   revert/userflips.sql
  #	modified:   sqitch.plan
  #
  # Untracked files:
  #   (use "git add <file>..." to include in what will be committed)
  #
  #	deploy/userflips@v1.0.0-dev2.sql
  #	revert/userflips@v1.0.0-dev2.sql
  #	verify/userflips@v1.0.0-dev2.sql
  no changes added to commit (use "git add" and/or "git commit -a")

The "untracked files" part of the output is the first thing to notice. They're
all named C<userflips@v1.0.0-dev2.sql>. What that means is: "the C<userflips>
change as it was implemented as of the C<@v1.0.0-dev2> tag." These are copies
of the original scripts, and thereafter Sqitch will find them when it needs to
run scripts for the first instance of the C<userflips> change. As such, it's
important not to change them again. But hey, if you're reworking the change,
you shouldn't need to.

The other thing to notice is that F<revert/userflips.sql> has changed. Sqitch
replaced it with the original deploy script. As of now,
F<deploy/userflips.sql> and F<revert/userflips.sql> are identical. This is on
the assumption that the deploy script will be changed (we're reworking it,
remember?), and that the revert script should actually change things back to
how they were before. Of course, the original deploy script may not be
L<idempotent|https://en.wikipedia.org/wiki/Idempotence> -- that is, able to be
applied multiple times without changing the result beyond the initial
application. If it's not, you will likely need to modify it so that it
properly restores things to how they were after the original deploy script was
deployed. Or, more simply, it should revert changes back to how they were
as-of the deployment of F<deploy/userflips@v1.0.0-dev2.sql>.

Fortunately, our function deploy scripts are already idempotent, thanks to the
use of the C<OR REPLACE> expression. No matter how many times a deployment
script is run, the end result will be the same instance of the function, with
no duplicates or errors.

As a result, there is no need to explicitly add changes. So go ahead. Modify
the script to add the C<twitter> column to the view. Make this change to
F<deploy/userflips.sql>:

  @@ -4,8 +4,9 @@
 
   BEGIN;
 
  @@ -4,6 +4,6 @@
   -- requires: flips
 
   CREATE OR REPLACE VIEW flipr.userflips AS
  -SELECT f.id, u.nickname, u.fullname, f.body, f.timestamp
  +SELECT f.id, u.nickname, u.fullname, u.twitter, f.body, f.timestamp
     FROM flipr.users u
     JOIN flipr.flips f ON u.nickname = f.nickname;

Next, modify F<verify/userflips.sql> to check for the C<twitter> column.
Here's the diff: