App-Sqitch

 view release on metacpan or  search on metacpan

lib/App/Sqitch/X.pm  view on Meta::CPAN

);

has '+previous_exception' => (init_arg => 'previous_exception')
    if Throwable->VERSION < 0.200007;

sub hurl {
    @_ = (
        __PACKAGE__,
        # Always pass $@, as Throwable is unreliable about getting it thanks
        # to hash randomization. Its workaround in v0.200006:
        # https://github.com/rjbs/throwable/commit/596dfbafed970a30324dc21539d4edf2cbda767a
        previous_exception => $@,
        ref $_[0]     ? %{ $_[0] }
            : @_ == 1 ? (message => $_[0])
            :           (ident => $_[0],  message => $_[1])
    );
    goto __PACKAGE__->can('throw');
}

sub as_string {
    my $self = shift;

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

=head2 Status, Revert, Log, Repeat

For purely informational purposes, we can always see how a deployment was
recorded via the L<C<status>|sqitch-status> command, which reads the tables
from the registry database:

  > sqitch status db:firebird://sysdba:masterkey@localhost//tmp/flipr_test/flipr.fdb
  # On database db:firebird://sysdba:@localhost//tmp/flipr_test/flipr.fdb
  # Project:  flipr
  # Change:   2cde9cc8c19161e9837de57741502243b2ad380e
  # Name:     users
  # Deployed: 2014-01-05 14:05:22 -0800
  # By:       Marge N. O’Vera <marge@example.com>
  # 
  Nothing to deploy (up-to-date)

Let's make sure that we can revert the change:

  > sqitch revert db:firebird://sysdba:masterkey@localhost//tmp/flipr_test/flipr.fdb
  Revert all changes from db:firebird://sysdba:@localhost//tmp/flipr_test/flipr.fdb? [Yes] 

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

  > sqitch verify db:firebird://sysdba:masterkey@localhost//tmp/flipr_test/flipr.fdb
  Verifying db:firebird://sysdba:@localhost//tmp/flipr_test/flipr.fdb
  No changes deployed

However, we still have a record that the change happened, visible via the
L<C<log>|sqitch-log> command:

  > sqitch log db:firebird://sysdba:masterkey@localhost//tmp/flipr_test/flipr.fdb
  On database db:firebird://sysdba:@localhost//tmp/flipr_test/flipr.fdb
  Revert 2cde9cc8c19161e9837de57741502243b2ad380e
  Name:      users
  Committer: Marge N. O’Vera <marge@example.com>
  Date:      2014-01-05 14:06:59 -0800

      Creates table to track our users.

  Deploy 2cde9cc8c19161e9837de57741502243b2ad380e
  Name:      users
  Committer: Marge N. O’Vera <marge@example.com>
  Date:      2014-01-05 14:05:22 -0800

      Creates table to track our users.


Note that the actions we took are shown in reverse chronological order, with
the revert first and then the deploy.

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

  > echo "CONNECT 'localhost:/tmp/flipr_test/flipr.fdb'; SHOW TABLES; quit;" \
    | isql-fb -q -u SYSDBA -p masterkey
         USERS                           

When we look at the status, the deployment will be there:

  > sqitch status db:firebird://sysdba:masterkey@localhost//tmp/flipr_test/flipr.fdb
  # On database db:firebird://sysdba:@localhost//tmp/flipr_test/flipr.fdb
  # Project:  flipr
  # Change:   2cde9cc8c19161e9837de57741502243b2ad380e
  # Name:     users
  # Deployed: 2014-01-05 14:19:32 -0800
  # By:       Marge N. O’Vera <marge@example.com>
  # 
  Nothing to deploy (up-to-date)

=head1 On Target

I'm getting a little tired of always having to type
C<db:firebird://sysdba:masterkey@localhost//tmp/flipr_test/flipr.fdb>, aren't

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

  > sqitch engine add firebird target flipr_test

Now we can omit the target argument altogether, unless we need to deploy to
another database. Which we will, eventually, but at least our examples will be
simpler from here on in, e.g.:

  > sqitch status
  # On database flipr_test
  # Project:  flipr
  # Change:   2cde9cc8c19161e9837de57741502243b2ad380e
  # Name:     users
  # Deployed: 2014-01-05 14:19:32 -0800
  # By:       Marge N. O’Vera <marge@example.com>
  # 
  Nothing to deploy (up-to-date)

Yay, that allows things to be a little more concise. Let's also make sure that
changes are verified after deploying them:

  > sqitch config --bool deploy.verify true

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

  > echo "CONNECT 'localhost:/tmp/flipr_test/flipr.fdb'; SHOW TABLES; quit;" \
    | isql-fb -q -u SYSDBA -p masterkey
       USERS                        

The L<C<status>|sqitch-status> command politely informs us that we have
undeployed changes:

  > sqitch status
  # On database flipr_test
  # Project:  flipr
  # Change:   2cde9cc8c19161e9837de57741502243b2ad380e
  # Name:     users
  # Deployed: 2014-01-05 14:19:32 -0800
  # By:       Marge N. O’Vera <marge@example.com>
  # 
  Undeployed change:
    * flips

As does the L<C<verify>|sqitch-verify> command:

  > sqitch verify

lib/sqitchtutorial.pod  view on Meta::CPAN

Uh-oh, someone just noticed that MD5 hashing is not particularly secure. Why?
Have a look at this:

  > psql -d flipr_test -c "
      SELECT flipr.insert_user('foo', 'secr3t'), flipr.insert_user('bar', 'secr3t');
      SELECT * FROM flipr.users;
  "
   nickname |             password             |           timestamp           
  ----------+----------------------------------+-------------------------------
   foo      | 9695da4dd567a19f9b92065f240c6725 | 2013-12-31 00:56:20.240481+00
   bar      | 9695da4dd567a19f9b92065f240c6725 | 2013-12-31 00:56:20.240481+00

If user "foo" ever got access to the database, she could quickly discover that
user "bar" has the same password and thus be able to exploit the account. Not
a great idea. So we need to modify the C<insert_user()> and C<change_pass()>
functions to fix that. How?

We'll use
L<C<pgcrypto>|https://www.postgresql.org/docs/current/static/pgcrypto.html>'s
C<crypt()> function to encrypt passwords with a salt, so that they're all
unique. We just add a change to add C<pgcrypto> to the database, and then we