App-Sqitch

 view release on metacpan or  search on metacpan

lib/App/Sqitch/Engine/clickhouse.pm  view on Meta::CPAN

            $self->registry, $self->registry_release,
        ),
    );

    # Deploy the registry to the Sqitch database.
    $self->run_upgrade( file(__FILE__)->dir->file('clickhouse.sql') );
    $self->_register_release;
}

sub _no_table_error  {
    # /HTTP status code: 404$/
    return $DBI::state && $DBI::state eq 'HY000'; # General Error
}

sub _no_column_error  {
    return $DBI::state && $DBI::state eq '42703'; # ERRCODE_UNDEFINED_COLUMN
}

sub _unique_error  {
    # ClickHouse doe not support unique constraints.
    return 0;

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

Looks good! If you want to make sure that the verify script correctly dies if
the schema doesn't exist, temporarily change the schema name in the script to
something that doesn't exist, something like:

  CREATE TABLE nonesuch.verify__ (id int);

Then L<C<verify>|sqitch-verify> again:

  > sqitch verify 'db:exasol://sys:exasol@localhost:8563/?Driver=Exasol'
  Verifying db:exasol://sys:@localhost:8563/?Driver=Exasol
  * appschema .. Error: [42000] schema NONESUCH not found [line 1, column 40] (Session: 1582884049218108749)

  # Verify script "verify/appschema.sql" failed.
  not ok

  Verify Summary Report
  ---------------------
  Changes: 1
  Errors:  1
  Verify failed

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

The other potentially useful symbolic tag is C<@ROOT>, which refers to the
first change deployed to the database (or in the plan, depending on the
command).

Back to the database. The C<users> table should be gone but the C<flipr> schema
should still be around:

  > echo "DESCRIBE flipr.users;" | sqlplus -S scott/tiger@flipr_test

  ERROR:
  ORA-04043: object flipr.users does not exist

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

  > sqitch status
  # On database flipr_test
  # Project:  flipr
  # Change:   c59e700589fc03568e8f35f592c0d9b7c638cbdd
  # Name:     appschema
  # Deployed: 2013-12-31 16:22:01 -0800

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

Looks good. Let's make sure revert works:

  > sqitch revert -y --to @HEAD^^
  Reverting changes to users from flipr_test
    - change_pass .. ok
    - insert_user .. ok
  > echo "DESCRIBE flipr.insert_user;\nDESCRIBE flipr.change_pass;" \
  | sqlplus -S dwheeler/dwheeler@flipr_test
  ERROR:
  ORA-04043: object flipr.insert_user does not exist

  ERROR:
  ORA-04043: object flipr.change_pass does not exist

Note the use of C<@HEAD^^> to specify that the revert be to two changes prior
the last deployed change. Looks good. Let's do the commit and re-deploy dance:

  > git add .
  > git commit -m 'Add `insert_user()` and `change_pass()`.'
  [main 6b6797e] Add `insert_user()` and `change_pass()`.
   7 files changed, 92 insertions(+)
   create mode 100644 deploy/change_pass.sql
   create mode 100644 deploy/insert_user.sql

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

  > 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

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