view release on metacpan or  search on metacpan

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

  > sqitch deploy 'db:snowflake://movera@example/flipr_prod?Driver=Snowflake'
  Adding registry tables to db:snowflake://movera@example/flipr_prod?Driver=Snowflake'
  Deploying changes to db:snowflake://movera@example/flipr_prod?Driver=Snowflake'
    + appschema ............... ok
    + users ................... ok
    + flips ................... ok
    + userflips @v1.0.0-dev1 .. ok

Notice how the tag on C<userflips> now appears in the deploy output. Nice, eh?
Now, package it up and ship it!

  > cd ..
  > mv bundle flipr-v1.0.0-dev1
  > tar -czf flipr-v1.0.0-dev1.tgz flipr-v1.0.0-dev1

=head1 Making a Hash of Things

Now that we've got the basics of the app done, let's add a feature. Gotta
track the hashtags associated with flips, right? Let's add a table for them.
But since other folks are working on other tasks in the repository, we'll work
on a branch, so we can all stay out of each other's way. So let's branch:

  > git checkout -b hashtags
  Switched to a new branch 'hashtags'

Now we can add a new change to create a table for hashtags.

  > sqitch add hashtags --requires flips -n 'Adds table for storing hashtags.'
  Created deploy/hashtags.sql
  Created revert/hashtags.sql
  Created verify/hashtags.sql
  Added "hashtags [appschema flips]" to sqitch.plan

You know the drill by now. Add this to F<deploy/hashtags.sql>

  CREATE TABLE flipr.hashtags (
      flip_id   INTEGER       NOT NULL REFERENCES flipr.flips(id),
      hashtag   VARCHAR(128)  NOT NULL,
      PRIMARY KEY (flip_id, hashtag)
  );

Again, select from the table in F<verify/hashtags.sql>:

  SELECT flip_id, hashtag FROM flipr.hashtags WHERE FALSE;

And drop it in F<revert/hashtags.sql>

  DROP TABLE flipr.hashtags;

And give it a whirl:

  > sqitch deploy
  Deploying changes to flipr_test
    + hashtags .. ok

Look good?

  > sqitch status --show-tags
  # On database flipr_test
  # Project:  flipr
  # Change:   d750cbeec487841c45715115a31297739fbb4046
  # Name:     hashtags
  # Deployed: 2018-07-27 11:53:02 -0400
  # By:       Marge N. O’Vera <marge@example.com>
  # 
  # Tag:
  #   @v1.0.0-dev1 - 2018-07-27 11:41:13 -0400 - Marge N. O’Vera <marge@example.com>
  # 
  Nothing to deploy (up-to-date)

Note the use of C<--show-tags> to show all the deployed tags. Make sure we can
revert, too:

  > sqitch revert -y --onto @HEAD^
  Reverting changes to userflips @v1.0.0-dev1 from flipr_test
    - hashtags .. ok
  > sqitch deploy
  Deploying changes to flipr_test
    + hashtags .. ok

Great! Now make it so:

  > git add .
  > git commit -m 'Add hashtags table.'
  [hashtags 06a0bf4] Add hashtags table.
   4 files changed, 19 insertions(+)
   create mode 100644 deploy/hashtags.sql
   create mode 100644 revert/hashtags.sql
   create mode 100644 verify/hashtags.sql

Good, we've finished this feature. Time to merge back into C<main>.

=head2 Emergency

Let's do it:

  > git checkout main
  Switched to branch 'main'
  > git pull
  Updating 84ed9db..31d026c
  Fast-forward
   deploy/lists.sql | 11 +++++++++++
   revert/lists.sql |  4 ++++
   sqitch.plan      |  2 ++
   verify/lists.sql |  6 ++++++
   4 files changed, 23 insertions(+)
   create mode 100644 deploy/lists.sql
   create mode 100644 revert/lists.sql
   create mode 100644 verify/lists.sql

Hrm, that's interesting. Looks like someone made some changes to C<main>.
They added list support. Well, let's see what happens when we merge our
changes.

  > git merge --no-ff hashtags
  Auto-merging sqitch.plan
  CONFLICT (content): Merge conflict in sqitch.plan
  Automatic merge failed; fix conflicts and then commit the result.

Oh, a conflict in F<sqitch.plan>. Not too surprising, since both the merged
C<lists> branch and our C<hashtags> branch added changes to the plan. Let's