Fix empty restrooms db during development

[DeeDeeG]

Fixes db being empty during development.
Ensures restroom entries from db/export.csv are loaded.

Context

• Copied the bundle exec rake db:setup command from the old Vagrant configurations.
• Makes it easier to test search and API pages
• Documentation/ reference:
  • This Stack Overflow answer: https://stackoverflow.com/questions/10301794/difference-between-rake-dbmigrate-dbreset-and-dbschemaload
  • The source code for these db functions: https://github.com/rails/rails/blob/v5.1.4/activerecord/lib/active_record/railties/databases.rake

Summary of Changes

• Remove db:create and db:migrate commands in setup/entry
• Replace with bundle exec rake db:setup

Checklist

• Tested Mobile Responsiveness
• Added Unit Tests
• CI Passes
• Deploys to Heroku on test Correctly (Maintainers will handle)
• Added Documentation (Service and Code when required)

Screenshots

Before

After

[DeeDeeG]

A more-minimal change might be to keep db:create and db:migrate, followed by db:seed.

I don't have time to test that at the moment. But the bundle exec rake db:setup command does work in my testing.

Edit: I have tested with the following commands, after deleting my local db docker image and starting from scratch with regard to the db, and it seems to function exactly the same as the commit above:

rake db:create
rake db:migrate
rake db:seed

I would go with either approach.

[DeeDeeG]

I'm hoping to merge this soon (in whichever configuration of commands we decide to go with) since it makes manual testing easier. It would particularly make the set of pull requests we have queued up easier to test.

[btyy77c]

Thanks for this!

Some comments:

1. In Rails 5 they changed the command from rake to rails. You would need to use rails db:setup now. I think rake db:setup will stop working with Rails 6:
   https://github.com/rails/rails/blob/master/railties/lib/rails/tasks/initializers.rake
   Move the initializers rake task to Rails::Command rails/rails#33631

2. Just to confirm, this docker-compose file is not used for production, correct? rails db:seed will harm your production database.
   If this is used for production, I would recommend instead running docker-compose run web rails db:setup in your terminal before you run docker-compose up to test things out locally... or creating a separate docker process for production.

3. Your restroom model has a geocoding method:
   https://github.com/RefugeRestrooms/refugerestrooms/blob/develop/app/models/restroom.rb

def perform_geocoding
      return true if Rails.env == "test"
      geocode
end

I think this is connecting to Google Api maps. When I run it, I get Google Geocoding API error: over query limit. It's not a huge deal, just so you're aware things may not be loading the way you want. I assume it's ok since you're skipping it for testing.

[DeeDeeG]

@btyy77c, thanks again for the informative feedback.

1. rails vs rake

Sounds right. I had this in the back of my head, but I don't think we've drop the rake command from our project, so I used rake out of habit and not "rocking the boat" just for this small pull request. Might be good to switch every rake in the repo at once to rails just to make sure it all works and get that convention change out of the way for the project.

2. Just to confirm, this docker-compose file is not used for production, correct? rails db:seed will harm your production database. . . .

I wish I knew this with high confidence. But I have the sense we are not using Docker whatsoever in production.

Production is a Heroku instance. I believe in that environment we get a minimal Linux "slug" that is able to then install ruby and our Gemfile and nodejs dependencies, etc. and generally run through our config files to set up a "native"-like Rails app on "bare" (virtual) metal. As in, no Docker or Vagrant etc.

Here is a file that I believe means there are three separate databases: one for development, one for testing, and by process of elimination, one for production (the "default" db): https://github.com/RefugeRestrooms/refugerestrooms/blob/develop/config/database.yml

Much of our app, especially as it pertains to Heroku, is set up roughly according to these guidelines: https://devcenter.heroku.com/articles/getting-started-with-rails5

3. Your restroom model has a geocoding method: . . .

I believe this is an inconsequential quirk/bug in our configs. I haven't seen this cause problems for us. I hope/presume it isn't actually counting against our quota. But other than that, this has felt safe to ignore. It would be nice to get rid of those warnings so people don't think something is going wrong, though.

(And the reason this isn't a big deal is that the entries we are loading at that point, from db/export.csv, already have lat/long coordinates. We don't need to geocode right there at all. I'm not sure why it happens to be honest.)

---

At bare minimum, I' going to switch this pull request to not use bundle exec (seems unnecessary) and to use rails db:[so-and-so] rather than rake db:[so-and-so].

[tkwidmer]

This LGTM @DeeDeeG, let's merge it asap since it seems like this is causing you and other people issues.

[DeeDeeG]

Alright. Testing with the latest commit locally just to be sure this works, then will merge.

I think our test environment (and our tests themselves) don't need the db/export.csv entries, so that's why CI didn't catch this.

edit: so for the moment this PR is mostly not able to trip up CI, but CI also isn't telling us anything useful about this being a good PR or not.

[tkwidmer]

Awesome. Thanks @DeeDeeG