Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

6.0.0rc1 Psych::BadAlias: Unknown alias: dummy_compiler in load_database_yaml #36540

Closed
klyonrad opened this issue Jun 23, 2019 · 8 comments · Fixed by #36560
Closed

6.0.0rc1 Psych::BadAlias: Unknown alias: dummy_compiler in load_database_yaml #36540

klyonrad opened this issue Jun 23, 2019 · 8 comments · Fixed by #36560
Assignees
Milestone

Comments

@klyonrad
Copy link

Steps to reproduce

database yaml

sqlite: &sqlite
  adapter: sqlite3
  database: db/test.sqlite3

postgresql: &postgresql
  adapter: postgresql
  username: postgres
  password:
  database: lazybar_ci_test
  min_messages: ERROR

defaults: &defaults
  pool: 5
  timeout: 5000
  host: localhost
  <<: *<%= ENV['DB'] || "sqlite" %>

test:
  <<: *defaults

$DB env variable is 'postgresql'

RAILS_ENV=test bundle exec rails db:migrate

Expected behavior

Successful execution of database migrations

Actual behavior

Following exception is raised:

rails aborted!
Psych::BadAlias: Unknown alias: dummy_compiler
/home/travis/build/klyonrad/lazybar/vendor/bundle/ruby/2.6.0/gems/railties-6.0.0.rc1/lib/rails/application/configuration.rb:207:in `load_database_yaml'
/home/travis/build/klyonrad/lazybar/vendor/bundle/ruby/2.6.0/gems/activerecord-6.0.0.rc1/lib/active_record/tasks/database_tasks.rb:147:in `for_each'
/home/travis/build/klyonrad/lazybar/vendor/bundle/ruby/2.6.0/gems/activerecord-6.0.0.rc1/lib/active_record/railties/databases.rake:26:in `block (2 levels) in <main>'
/home/travis/build/klyonrad/lazybar/vendor/bundle/ruby/2.6.0/gems/activerecord-6.0.0.rc1/lib/active_record/railties/databases.rake:21:in `block in <main>'
/home/travis/build/klyonrad/lazybar/vendor/bundle/ruby/2.6.0/gems/activerecord-6.0.0.rc1/lib/active_record/railties/databases.rake:5:in `<main>'
/home/travis/build/klyonrad/lazybar/vendor/bundle/ruby/2.6.0/gems/bootsnap-1.4.4/lib/bootsnap/load_path_cache/core_ext/kernel_require.rb:69:in `load'

....

/lib/active_support/dependencies.rb:302:in `require'
bin/rails:4:in `<main>'
Caused by:
Bootsnap::LoadPathCache::FallbackScan: 

System configuration

Rails version: 6.0.0.rc1

Ruby version: 2.6.3

Additional Notes

I removed the inline ERB and then it went through.

klyonrad added a commit to klyonrad/lazybar that referenced this issue Jun 23, 2019
Because of rails/rails#35497
(rails commit 37d1429ab1da78a3b8afcfcec8a135ac85cd897a)

Bug report for rails is here: rails/rails#36540
@klyonrad
Copy link
Author

klyonrad commented Jun 23, 2019

I assume this has to do with #35497, but is not fixed by #36237.

Brushing the terrible readability from my database yml aside, I think it would be good for rails users to have some kind of better error message

klyonrad added a commit to klyonrad/lazybar that referenced this issue Jun 23, 2019
Because of rails/rails#35497
(rails commit 37d1429ab1da78a3b8afcfcec8a135ac85cd897a)

Bug report for rails is here: rails/rails#36540
@y-yagi
Copy link
Member

y-yagi commented Jun 23, 2019

DummyCompiler improved by #36286, but seems still can't parse YML specified in the issue.

$ cat tmp/database.yml
sqlite: &sqlite
  adapter: sqlite3
  database: db/test.sqlite3

postgresql: &postgresql
  adapter: postgresql
  username: postgres
  password:
  database: lazybar_ci_test
  min_messages: ERROR

defaults: &defaults
  pool: 5
  timeout: 5000
  host: localhost
  <<: *<%= ENV['DB'] || "sqlite" %>

test:
  <<: *defaults 

$ ./bin/rails r 'require "rails/application/dummy_erb_compiler"; YAML.load(DummyERB.new(Pathname.new("tmp/database.yml").read).result)'
Traceback (most recent call last):
	14: from ./bin/rails:4:in `<main>'
	13: from ./bin/rails:4:in `require'
	12: from /home/yaginuma/program/rails/master_y_yagi/rails/railties/lib/rails/commands.rb:18:in `<top (required)>'
	11: from /home/yaginuma/program/rails/master_y_yagi/rails/railties/lib/rails/command.rb:46:in `invoke'
	10: from /home/yaginuma/program/rails/master_y_yagi/rails/railties/lib/rails/command/base.rb:65:in `perform'
	 9: from /home/yaginuma/.rbenv/versions/2.6.2/lib/ruby/gems/2.6.0/gems/thor-0.20.3/lib/thor.rb:387:in `dispatch'
	 8: from /home/yaginuma/.rbenv/versions/2.6.2/lib/ruby/gems/2.6.0/gems/thor-0.20.3/lib/thor/invocation.rb:126:in `invoke_command'
	 7: from /home/yaginuma/.rbenv/versions/2.6.2/lib/ruby/gems/2.6.0/gems/thor-0.20.3/lib/thor/command.rb:27:in `run'
	 6: from /home/yaginuma/program/rails/master_y_yagi/rails/railties/lib/rails/commands/runner/runner_command.rb:45:in `perform'
	 5: from /home/yaginuma/program/rails/master_y_yagi/rails/railties/lib/rails/commands/runner/runner_command.rb:45:in `eval'
	 4: from /home/yaginuma/program/rails/master_y_yagi/rails/railties/lib/rails/commands/runner/runner_command.rb:45:in `<main>'
	 3: from /home/yaginuma/.rbenv/versions/2.6.2/lib/ruby/2.6.0/psych.rb:277:in `load'
	 2: from /home/yaginuma/.rbenv/versions/2.6.2/lib/ruby/2.6.0/psych.rb:390:in `parse'
	 1: from /home/yaginuma/.rbenv/versions/2.6.2/lib/ruby/2.6.0/psych.rb:456:in `parse_stream'
/home/yaginuma/.rbenv/versions/2.6.2/lib/ruby/2.6.0/psych.rb:456:in `parse': (<unknown>): did not find expected alphabetic or numeric character while scanning an alias at line 16 column 7 (Psych::SyntaxError) 

@eileencodes eileencodes self-assigned this Jun 24, 2019
@eileencodes eileencodes added this to the 6.0.0 milestone Jun 24, 2019
@eileencodes
Copy link
Member

eileencodes commented Jun 24, 2019

Is there more to this database.yml? I'm sorry but I don't understand what it's doing. Why is there only a test env? When and where is sqlite3 getting used?

@rafaelfranca
Copy link
Member

When and where is sqlite3 getting used?

Here:

defaults: &defaults
  pool: 5
  timeout: 5000
  host: localhost
  <<: *<%= ENV['DB'] || "sqlite" %> # sqlite is being used here

@eileencodes
Copy link
Member

I mean where is it being used in real life. I don't get why you'd want to do this - it seems like test and prod are using different databases but I don't see a prod definition in there. Is this for a ci thing?

@rafaelfranca
Copy link
Member

I think it is related to CI. It is being used to swap the test database adapter with an environment variable. The postgresql and sqlite entries contains the different configs for those adapters and all the common configs are in the defaults (they could be in test too)

@klyonrad
Copy link
Author

Yeah that’s what I wanted to achieve with this back then - probably just copied from a blog post like this https://rubytutorial.io/travis-ci-multiple-database/

Like I said, it has a terrible readability 😉 and personally I just deactivated that again, but who knows what other kind of database.yml files are out there and I just wanted to share my bug report :)

eileencodes added a commit to eileencodes/rails that referenced this issue Jun 27, 2019
For multiple databases we attempt to generate the tasks by reading the
database.yml before the Rails application is booted. This means that we
need to strip out ERB since it could be reading Rails configs.

In some cases like rails#36540 the ERB
is too complex and we can't overwrite with the DummyCompilier we used in
rails#35497. For the complex causes we
simply issue a warning that says we couldn't infer the database tasks
from the database.yml.

While working on this I decided to update the code to only load the
database.yml once initially so that we avoid having to issue the same
warning multiple times. Note that this had no performance impact in my
testing and is merely for not having to save the error off somewhere.
Also this feels cleaner.

Note that this will not break running tasks that exist, it will just
mean that tasks for multi-db like `db:create:other_db` will not be
generated. If the database.yml is actually unreadable it will blow up
during normal rake task calls.

Fixes rails#36540
@eileencodes
Copy link
Member

This is kind of fixed 😅 Since we only use this to generate the tasks for you I've decided to rescue and issue a warning if the yaml is too complex for our task generator to read. The traditional tasks will all work and we'll no longer throw an exception. Hope this is a good compromise. Thanks for the report and explantation!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants