Deprecation Warning in fresh project
pedz opened this issue · 6 comments
I'm trying to start a new project that uses ActiveRecord but not Rails. I am looking at the README here as well as following suggestions from this web page. When I do bundle exec rake --tasks I get the following warning:
DEPRECATION WARNING: ActiveRecord::Base.schema_format is deprecated and will be removed in Rails 7.1.
Use `ActiveRecord.schema_format` instead.
(called from <top (required)> at /usr/home/pedz/source/find-duplicates/Rakefile:4)
rake aborted!
NoMethodError: undefined method `schema_file' for primary:Module
default_schema = ENV['SCHEMA'] || ActiveRecord::Tasks::DatabaseTasks.schema_file(ActiveRecord::Base.schema_format)
^^^^^^^^^^^^
Did you mean? schema_file_type
/usr/home/pedz/source/find-duplicates/Rakefile:4:in `<top (required)>'
(See full trace by running task with --trace)
Gemfile:
source 'https://rubygems.org'
gem 'activerecord'
gem 'standalone_migrations'
gem 'pg'
Rakefile
# Home page for migrations:
# https://github.com/thuss/standalone-migrations
require 'standalone_migrations'
StandaloneMigrations::Tasks.load_tasks
db/config.yml
default: &default
adapter: postgresql
encoding: unicode
pool: 5
host: localhost
development:
<<: *default
database: files_development
test: &test
<<: *default
database: files_test
production:
<<: *default
database: files_production
I will try to dig into this myself but I've not done Ruby projects since about 2018 so I'm much slower at digging into a debugging things than I use to be.
The deprecation of ActiveRecord::Base#schema_file was done on Dec 29, 2020 in commit 3688a2e01a471acacd13b54eddf57e97d24466f8 -- 14+ months ago. Not a super long time for folks to adjust be I guess it is fair. There is now a new db_dir attribute in some config file somewhere but I'm still trying to understand the code. Currently I don't see how it isn't a catch 22 problem where db_dir must defined before you can fetch the value of db_dir from the config files but I'm still groping around in the dark more or less.
The deprecation of
ActiveRecord::Base#schema_filewas done on Dec 29, 2020 in commit 3688a2e01a471acacd13b54eddf57e97d24466f8 -- 14+ months ago. Not a super long time for folks to adjust be I guess it is fair. There is now a newdb_dirattribute in some config file somewhere but I'm still trying to understand the code. Currently I don't see how it isn't a catch 22 problem where db_dir must defined before you can fetch the value of db_dir from the config files but I'm still groping around in the dark more or less.
I poked around in pry(-byebug)/irb and probably found the same trouble, a dependency cycle where to access the data we want, we would already need an active configuration loaded, given as a parameter to those functions.
So I just added a string literal, included internally, with the current, commonly expected default.
Maybe another time I can have it stop making an empty db directory in the project root next O_o..
I would try with the latest standalone migrations. I setup the test project you mention above and after running bundle install and bundle exec rake --tasks I don't get any deprecation warnings. Let me know if I'm missing something?
Finally updated to 7.1.2, wasn't before for some reason..
Tried creating a minimal scenario to show the problem I was still having, but I guess that is stuck by #153 still?. I say that because of the command mentioned in this issue, but even having that basic, single-database configuration and issuing project-recommended commands show the same failure, and I don't see other issues explaining my current problem:
> mkdir test
> pushd test
> gem list standalone_migrations
*** LOCAL GEMS ***
standalone_migrations (7.1.2)
> cat > Rakefile
require 'standalone_migrations'
StandaloneMigrations::Tasks.load_tasks
> mkdir db
> cat > db/config.yaml
development:
adapter: sqlite3
database: db/development.sqlite3
<......>
> wc -l db/config.yaml
21 db/config.yaml
> rake --tasks
rake aborted!
Cannot load database configuration:
Could not load database configuration. No such file - ["db/config.yml"]
$HOME/.local/share/gem/ruby/3.2.0/gems/railties-7.0.8/lib/rails/application/configuration.rb:352:in `database_configuration'
$HOME/.local/share/gem/ruby/3.2.0/gems/standalone_migrations-7.1.2/lib/standalone_migrations/configurator.rb:24:in `load_configurations'
$HOME/.local/share/gem/ruby/3.2.0/gems/standalone_migrations-7.1.2/lib/standalone_migrations/configurator.rb:30:in `environments_config'
$HOME/.local/share/gem/ruby/3.2.0/gems/standalone_migrations-7.1.2/lib/standalone_migrations/tasks.rb:11:in `load_tasks'
$HOME/test/Rakefile:2:in `<top (required)>'
$HOME/.local/share/gem/ruby/3.2.0/gems/rake-13.1.0/exe/rake:27:in `<top (required)>'
Caused by:
Could not load database configuration. No such file - ["db/config.yml"]
$HOME/.local/share/gem/ruby/3.2.0/gems/railties-7.0.8/lib/rails/application/configuration.rb:352:in `database_configuration'
$HOME/.local/share/gem/ruby/3.2.0/gems/standalone_migrations-7.1.2/lib/standalone_migrations/configurator.rb:24:in `load_configurations'
$HOME/.local/share/gem/ruby/3.2.0/gems/standalone_migrations-7.1.2/lib/standalone_migrations/configurator.rb:30:in `environments_config'
$HOME/.local/share/gem/ruby/3.2.0/gems/standalone_migrations-7.1.2/lib/standalone_migrations/tasks.rb:11:in `load_tasks'
$HOME/test/Rakefile:2:in `<top (required)>'
$HOME/.local/share/gem/ruby/3.2.0/gems/rake-13.1.0/exe/rake:27:in `<top (required)>'
(See full trace by running task with --trace)
> rake db:migrate:status
<same error>
> find -mindepth 1 -type f
./db/config.yaml
./Rakefile
> ls -l db/config.yaml
-rw-r--r--. 1 <username> <username> 94 Nov 13 14:58 db/config.yaml
> ruby -v
ruby 3.2.2 (2023-03-30 revision e51014f9c0) [x86_64-linux]
> gem -v
3.4.20
> neofetch --stdout distro kernel shell
distro: Fedora release 39 (Thirty Nine) x86_64
kernel: 6.5.11-300.fc39.x86_64
shell: fish 3.6.1
You should be creating a file called config.yml (not config.yaml).
I followed the exact same steps you listed above and it worked for me using the correct filename.
That fixed it.. Also checked my other situation. Once I actually got the gem updated I don't see any issues there either now besides that folder still being created. Searching mkdir for this gem only shows specs, so probably ActiveRecord doing it.