Doesn't propogate initial database with Pg

[thowe]

When using sqlite, the admin user and at least one page gets added to the database on Deploy. When using Pg, the database schema is deployed, but it is empty. I get an odd message. Log:

[Mon Feb 3 20:33:31 2014] [debug] POST "/database_install". [Mon Feb 3 20:33:31 2014] [debug] Routing to a callback. NOTICE: CREATE TABLE will create implicit sequence "dbix_class_deploymenthandler_versions_id_seq" for serial column "dbix_class_deploymenthandler_versions.id" NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "dbix_class_deploymenthandler_versions_pkey" for table "dbix_class_deploymenthandler_versions" NOTICE: CREATE TABLE / UNIQUE will create implicit index "dbix_class_deploymenthandler_versions_version" for table "dbix_class_deploymenthandler_versions" NOTICE: CREATE TABLE will create implicit sequence "menus_menu_id_seq" for serial column "menus.menu_id" NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "menus_pkey" for table "menus" NOTICE: CREATE TABLE / UNIQUE will create implicit index "menus_name" for table "menus" NOTICE: CREATE TABLE will create implicit sequence "users_user_id_seq" for serial column "users.user_id" NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "users_pkey" for table "users" NOTICE: CREATE TABLE / UNIQUE will create implicit index "users_name" for table "users" NOTICE: CREATE TABLE will create implicit sequence "pages_page_id_seq" for serial column "pages.page_id" NOTICE: CREATE TABLE / PRIMARY KEY will create implicit index "pages_pkey" for table "pages" NOTICE: CREATE TABLE / UNIQUE will create implicit index "pages_name" for table "pages" Overwriting existing DDL-YML file - /tmp/nIYsp6RRwA/_source/deploy/2/001-auto.yml at /home/tim/perl5/lib/site_perl/5.16.3/x86_64-linux/Moose/Meta/Method/Delegation.pm line 110. Overwriting existing DDL-YML file - /tmp/nIYsp6RRwA/_source/deploy/2/001-auto-__VERSION.yml at /home/tim/perl5/lib/site_perl/5.16.3/x86_64-linux/Moose/Meta/Method/Delegation.pm line 110.

[hrupprecht]

Hi thowe,

I've had a time ago same issue. See my first patch which was rejected. Then I was gone with MySQL. Reason was a missing

$schema->storage->sql_maker->quote_char([ qw/" "/] );
$schema->storage->sql_maker->name_sep('.');

for the deployment handler in lib/Galileo/Command/setup.pm when db == Pg in line 44-47

@jberger : I can track this down again and send you a patch.

[hrupprecht]

Here my config from these days. Have a look at the utf8 stuff in db_options too.

     {
      'db_dsn' => 'dbi:Pg:dbname=galileo;host=127.0.0.1;port=5432',
      'db_options' => {
        AutoCommit => 1,
        RaiseError => 1,
        PrintError => 1,
        pg_utf8_strings => 1,
        on_connect_do => 'SET search_path TO public,galileo',
        pg_enable_utf8 => 1,
      },
      'db_password' => 'galileo',
      'db_schema' => 'Galileo::DB::Schema',
      'db_username' => 'galileo',
      'extra_css' => [
        '/themes/standard.css'
      ],
      'extra_js' => [],
      'extra_static_paths' => [
        '/home/web/Galileo/static'
      ],
      'sanitize' => '1',
      'secret' => "idontnoanymore",
      'upload_path' => 'uploads',
    }

[hrupprecht]

Got it !

[thowe]

On Mon, 03 Feb 2014 23:57:08 -0800 Holger Rupprecht notifications@github.com wrote:

Hi thowe,

I've had a time ago same issue. See [my first patch][1] which was rejected. Then I was gone with MySQL. Reason was a missing

$schema->storage->sql_maker->quote_char([ qw/" "/] );
$schema->storage->sql_maker->name_sep('.');

Yes, after thinking about it more I suspected that I just

needed to turn on quote_names. I use this for one of my Catalyst apps (https://github.com/thowe/PieNg/blob/master/pieng.conf) that has similar column names, so I should have thought of it sooner.

I will test tonight.

--TimH

[thowe]

Indeed, on database setup passing the options (JSON hash) "{"quote_names":1}" fixed the issue. I think the only needed fix would be to mention this in the setup readme.

[hrupprecht]

Yeah, solve it with a config option is more clever than fix it in code! Cheers. @jberger please reject my pull request!

[jberger]

I was hoping to look through the dbicdh docs to see if there is was an easy way to configure per db options, but that wouldn't fix run time use.

[jberger]

Closing for now. If someone comes up with a clever solution to per-db initial configuration, I would happily consider a patch.