decko seed on postgresql generates errors about decko

[ethn]

I just double-checked to confirm that nothing mysql-specific had crept into our schema specification. It looks clean to me: https://github.com/decko-commons/decko/blob/master/card/db/schema.rb

So my first guess is that the problem is in the Gemfile. If you create a new deck with the -d option you can get presets for a given database engine; otherwise it will give you mysql defaults. Does the mysql gem show up in your Gemfile? Does switching that to the pg gem work?

[tukanos]

Thank you Ethan for suggestions, apparently the major reason why it did not install were the mysql leftovers from previous installation.

The code looks good to me. (Note: it would be good to know why there are some limits imposed - e.g. create_table "card_changes" -> t.text "value", limit: 16777215 (most probably DB is the limiting factor here) but still a comment like # nvarchar limit) would help in understanding the limits)

I have concluded that message is then a leftover from the MySQL test I was doing. Also the pg gem version had cause an issue.

Yesterday I went back and uninstalled all the gems. Installed rvm - took version 2.3.0 & gemset. Now I have managed to install the Decko application with PostgreSQL 9.4.

First, it would be good to know which version of pg gem is supported. I have tried pg version 1.0.0. but it did not work. After I have uninstalled the pg 1.0.0 gem and put a gem 'pg', '~> 0.18' into the Gemfile. The version pg (0.21.0) was installed.

Also the ../config/database.yml - how it should exactly look like in production use?

The steps to make Decko working on Centos 7 - complete log (postgresql 9.4 (not a stock one!) could be easily adjusted to any newer than 9.4 version):

install posgresql 9.4

mkdir install_pg
cd install_pg
wget  https://yum.postgresql.org/9.4/redhat/rhel-7-x86_64/pgdg-centos94-9.4-3.noarch.rpm
sudo yum -y install http://yum.postgresql.org/9.4/redhat/rhel-7-x86_64/pgdg-centos94-9.4-3.noarch.rpm
sudo yum -y groupinstall "PostgreSQL Database Server 9.4 PGDG"

check if everything was correctly installed

sudo rpm -qa | grep postgre
postgresql94-server-9.4.16-1PGDG.rhel7.x86_64
postgresql94-libs-9.4.16-1PGDG.rhel7.x86_64
postgresql94-9.4.16-1PGDG.rhel7.x86_64
postgresql94-contrib-9.4.16-1PGDG.rhel7.x86_64

enable & start service

sudo systemctl enable postgresql-9.4
sudo systemctl start postgresql-9.4.service

initialize database

sudo /usr/pgsql-9.4/bin/postgresql94-setup initdb

firewall adjustment (open ports)

firewall-cmd --permanent --add-port=5432/tcp
firewall-cmd --permanent --add-port=80/tcp
firewall-cmd --reload

enable SELinux

setsebool -P httpd_can_network_connect_db 1

change password for the

sudo passwd postgres (user promted twice for a password)

edit the posgresql configuration file

vim /var/lib/pgsql/9.4/data/pg_hba.conf
Change from:
host    all             all             127.0.0.1/32            ident
# IPv6 local connections:
host    all             all             ::1/128                 ident

To:
host    all             all             127.0.0.1/32            md5
# IPv6 local connections:
host    all             all             ::1/128                 md5

posgresql 9.4 binaries (should set postgresql ENV!)

all postgresql 9.4 binaries are installed at /usr/pgsql-9.4/bin

Change password for the 'postgres' user

sudo passwd postgres

If root/sudo rights are unavailable use sudo:
sudo -i -u postgres
at the prompt then enter:
passwd to change the user password

Decko installation

create a db user (asks for the password twice) will have to be written at the config/database.yml

# -d (--createdb) (role can create new databases)
# -P (--pwprompt) (assign a password to new role)
createuser -d <db_user> -P (CREATE ROLE alias)

create database which will have to be written at the config/database.yml

# probably not needed decko seed will create the database
# create database via user
# -O (--owner=OWner) (database user to own the new database)
# createdb -O <db_user> <database>

Edit Gemfile and add the pg gem

gem 'pg', '~> 0.18'

edit config/database.yml

# Add this after the cucumber: *test line

production: &production
  adapter: postgresql
  encoding: utf8
  reconnect: false
  database: <database_name>
  pool: 5
  username: <db_user>
  password: <db_user_password>
  host: localhost

I'm fuzzy here on the profile (probably if you want to change to production then change it?)
@ethn could you please fill it here?
profile: *production

What is the correct format for production deployment?

Now to install all gems and seed the application

install decko gem

gem install decko

install new application

decko new _app_name_

change directory

cd _app_name_

install all needed gems (this is probably optional but I'm used to doing it manually)

bundle install

prefill the DB and have the original configuration

decko seed

If everything went fine you should see:

bundle exec rake decko:seed
--> Database '<db_name>' already exists  (This is extra as I had the database already)
not dropped
creating
loading schema
-- create_table("card_actions", {:id=>:integer, :force=>:cascade})
   -> 0.0542s
-- create_table("card_acts", {:id=>:integer, :force=>:cascade})
   -> 0.0250s
-- create_table("card_changes", {:id=>:integer, :force=>:cascade})
   -> 0.0121s
-- create_table("card_references", {:id=>:integer, :force=>:cascade})
   -> 0.0290s
-- create_table("card_revisions", {:id=>:integer, :force=>:cascade})
   -> 0.0157s
-- create_table("cards", {:id=>:integer, :force=>:cascade})
   -> 0.0571s
-- create_table("delayed_jobs", {:force=>:cascade})
   -> 0.0146s
-- create_table("schema_migrations_core_cards", {:id=>false, :force=>:cascade})
   -> 0.0095s
-- create_table("schema_migrations_deck_cards", {:id=>false, :force=>:cascade})
   -> 0.0084s
-- create_table("sessions", {:id=>:integer, :force=>:cascade})
   -> 0.0107s
-- create_table("users", {:id=>:integer, :force=>:cascade})
   -> 0.0073s
update card_migrations
-- assume_migrated_upto_version("20170830210517", ["/home/smalltalk/.rvm/gems/ruby-2.3.0/gems/card-1.93.8/db/migrate_core_cards"])
   -> 0.0321s
loading bootstrap
set symlink for assets
reset cache

Then you can start the built-in WEBrick server as mentioned at the https://github.com/decko-commons/decko/blob/master/decko/README.rdoc

You should see (when started correctly):

decko server
=> Booting Thin
=> Rails 5.1.4 application starting in production on http://0.0.0.0:3000
=> Run `rails server -h` for more startup options
Thin web server (v1.7.2 codename Bachmanity)
Maximum connections set to 1024
Listening on 0.0.0.0:3000, CTRL+C to stop

[ethn]

Wow, thanks for all this. I know that the installation instructions on wagn.org are a bit of a mess; this will be a huge help in updating them.

Re postgres versions, our continuous integration tests (on Semaphore) start with a fresh copy of the latest code using --database=postgresql and update the gem bundle, so this means it is using the latest version of the pg gem. I'm not sure what version of postgres it uses, honestly. I'll have to dig into to figure out what those version numbers are; it's not something we tweak much. It occurs to me I'll need to be systematic about this for us to be able to keep the README current.

Re config/database.yml, you would really only need to add a lot more there if you wanted to work on decko code and run your code in many different environments (test, develop, etc). "profile" is just another of those environments; one optimized for doing performance profiling of the code. If you really do want these environments, the easiest way to see an example of a database.yml that does that is to create a new "core-dev" deck with decko new --core-dev mydeckname.

The more important thing for getting wagn performing well in production is getting going with memcached. I think you broached that topic in another issue, but the key link is wagn.org/wagn_in_production.

[tukanos]

@ethn

It occurs to me I'll need to be systematic about this for us to be able to keep the README current.

Yes that is the only way to do it. Maybe it would be a good approach to take the file versions automatically from some running instance.

Thank you for the information. I'll hope I'll have it running soon. My hosting has ancient ruby so they will have to upgrade first.

[ethn]

OK, I've

• come up with a working solution for the README / dependencies issue (see other conversation)
• added your postgres story to wagn.org. Thank you again! I've got a long-term goal of separating out step-by-step documentation from reference documentation and made some small steps in that direction. This is one of the most detailed step-by-step "stories" we have.
• I made pivotal tracker (our main organizer) stories for schema.rb comments and testing the recent versions of the pg gem, because I'm afraid those issues would get lost in this issue.

So I think we're good to close this one?

[tukanos]

Yes, we are. Thank you!