Seeding Discourse's database in a testing environment

(Silver Quettier) #1

I’m tinkering with Discourse a bit, learning some Ruby and moving towards writing a few plugins.

I have a dev VM (Vagrant-powered), and would like to have test data ready for me there. Even better, if a fellow member-developper of my community clones my Git repo, I would like him to have all the test data there without any effort.

My solution was to directly edit the db/fixtures/*.rb files to insert all the data I need in database. But it seems its not working as I thought it was.

My 001_categories.rb:

# fix any bust caches post initial migration
ActiveRecord::Base.send(:subclasses).each{|m| m.reset_column_information}

if SiteSetting.uncategorized_category_id == -1 || !Category.exists?(SiteSetting.uncategorized_category_id)
  puts "Seeding uncategorized category!"

  result = Category.exec_sql "SELECT 1 FROM categories WHERE lower(name) = 'uncategorized'"
  name = 'Uncategorized'
  if result.count > 0
    name << SecureRandom.hex

  result = Category.exec_sql "INSERT INTO categories
          (name,color,slug,description,text_color, user_id, created_at, updated_at, position, name_lower)
   VALUES ('#{name}', 'AB9364', 'uncategorized', '', 'FFFFFF', -1, now(), now(), 1, '#{name.downcase}' )
  category_id = result[0]["id"].to_i

  Category.exec_sql "DELETE FROM site_settings where name = 'uncategorized_category_id'"
  Category.exec_sql "INSERT INTO site_settings(name, data_type, value, created_at, updated_at)
           VALUES ('uncategorized_category_id', 3, #{category_id}, now(), now())"

  Category.exec_sql "INSERT INTO categories
          (name,color,slug,description,text_color, user_id, created_at, updated_at, position, name_lower)
   VALUES ('Idées', 'bcb5ad', 'idees', 'Exprimez vos idées !', 'FFFFFF', -1, now(), now(), 2, 'idées' )

This last INSERT block is mine, and should add a new (and very française) category of my own in there.

Thing is… After a bundle exec rake db:migrate… it doesnt. What am I doing wrong?

(Robin Ward) #2

It will be much easier if you just include a postgres dump or discourse backup in your repo.

If you have a postgres dump a developer can import it with one command:

$ psql discourse_development < your_db_dump.sql

If you include a discourse backup in public/backups/default, they can also import it with one command:

$ script/discourse import backup-file-name.tar.gz

(Silver Quettier) #3

Thank you @eviltrout , sorry for the delay in acknowledging your answer… I was stuck by other problems.

I am trying to restore a discourse backup (created in development environment) in the testing environment. Here is what I get from the command line:

discourse@container-app:/var/www/discourse$ script/discourse import discourse-1-0-2015-07-15-095155.tar.gz
Starting restore: discourse-1-0-2015-07-15-095155.tar.gz
/var/www/discourse/lib/backup_restore/restorer.rb:77:in `ensure_restore_is_enabled': uninitialized constant BackupRestore::Restorer::Restore (NameError)
        from /var/www/discourse/lib/backup_restore/restorer.rb:13:in `initialize'
        from script/discourse:78:in `new'
        from script/discourse:78:in `restore'
        from script/discourse:94:in `import'
        from /usr/local/lib/ruby/gems/2.0.0/gems/thor-0.19.1/lib/thor/command.rb:27:in `run'
        from /usr/local/lib/ruby/gems/2.0.0/gems/thor-0.19.1/lib/thor/invocation.rb:126:in `invoke_command'
        from /usr/local/lib/ruby/gems/2.0.0/gems/thor-0.19.1/lib/thor.rb:359:in `dispatch'
        from /usr/local/lib/ruby/gems/2.0.0/gems/thor-0.19.1/lib/thor/base.rb:440:in `start'
        from script/discourse:161:in `<main>'

From what I understand, this is due to the “allow restore” option not being active in Discourse’s admin. Makes sense.

However, here’s the catch:

This testing environment cannot send mail. Mailcatcher does not work (as this is a Docker install, not Vagrant VM), and “normal” mail sending does not either, due to a corporate proxy sandboxing our testing environment. I was kinda hoping to bypass mail activation for the first user precisely by restoring that backup.

Is there something I can do to set the “allow restore” configuration parameter to true from the command line?

(Robin Ward) #4

Yes, you can do this:

$ bundle exec rails console
[1] pry(main)> SiteSetting.allow_restore = true