Add rails db:system:change command

[gmcgibbon]

Part two of #34710.

After studying up commands and generators, I decided to make a command that delegates to a generator (similar to rails new / app generator). This seems to give us the most flexibility with how the command interacts with files, and if the user wants to accept the config overwrites or not.

TODO:

• Fix three level nested generator lookup
• Add tests for generator with file assertions
• Add chagelog entry

[eileencodes]

I like this. I left 2 minor comments.

[eileencodes]

I like this. I left 2 minor comments.

[eileencodes]

Should this raise an error if we get to the else? Otherwise I think this will silently fail.

[gmcgibbon]

I don't think so, sqlite3 and ibm_db have a direct adapter name to gem name mapping with no version locking. The value itself should be validated by the #initialize check in ChangeGenerator.

[kaspth]

What do these new lines do? I've always found the base and context naming here confusing?

[gmcgibbon]

I'm essentially only adding lookups << "rails:#{base}:#{name}" if a base exists. This is necessary due to the second part of the lookup code:

unless base || context
  unless name.to_s.include?(?:)
    lookups << "#{name}:#{name}"
    lookups << "rails:#{name}"
  end
  lookups << "#{name}"
end

Specifically, lookups << "rails:#{name}" which limits us to looking up single segment generator names in the toplevel rails namespace.

When looking up rails g db:system:change, name is the last segment ("change"), base is the namespace path ("db:system"), and context is nil. I think context is used if name isn't the command name, but I'm not sure why. Maybe we should change base to path?

[kaspth]

So it's possible for users to call rails g db:system:change? I thought this generator was internal and sufficiently called via it's class start method from the command?

[gmcgibbon]

That is currently possible, yes. If we don't want it to be possible, and only called via the command, I can remove this patch to #find_by_namespace. WDYT?

[gmcgibbon]

I'll go ahead and revert the changes to the generator lookup and hide this generator so it can only be called through the command. I'm assuming we would prefer only one way of changing databases.

[kaspth]

You're getting pretty adept at finding your way around the codebase! Lovely to see 💪

[kaspth]

You're getting pretty adept at finding your way around the codebase! Lovely to see 💪

[kaspth]

Do we generally say DBMS elsewhere?

[gmcgibbon]

Only once in a comment of activerecord/lib/active_record/connection_adapters/abstract_adapter.rb. I see RDBMS in guides/source/active_record_basics.md and activerecord/lib/active_record/connection_adapters/abstract/schema_statements.rb, but I don't think that's much better. I'll change it to database for now.

[matthewd]

Try "database type"? It's not brilliant, but maybe an improvement? Or "database platform"?

[kaspth]

Using "database system" would match the command name and reinforce the concept. But it's perhaps not expounding on what a "database system" means, that meaning only comes from seeing MySQL, Postgres and the gang.

[gmcgibbon]

Agree that database system makes the most sense given the command name. Will use that

[kaspth]

Curiosity for another time: since 2.6 allows constants to start with non ascii characters, does that mean we could name a Rails app, say, 666?

[jrochkind]

@kaspth not 666, because it needs to begin with something the unicode database as included in the particular ruby version thinks is an uppercase letter. Just not limited to ascii.

[kaspth]

How will we have to maintain these Gemfiles going forward?

[gmcgibbon]

Good question. I initially tried to generate all test apps without --skip-gemfile, but then rails will run bundle install and crash because rails 6 isn't released yet. I just noticed we have skip_bundle as an app generator option, so I'll try using that, and using the gem template in generator tests.

[kaspth]

Adding a newline after output and between the assert_file seems like it would increase readability in these tests.

[kaspth]

For another time: seeing this deep module nesting makes me think we should consider adding something akin to Action Mailboxes' routing for commands.

[kaspth]

Forgot to ask, how are we handling cases where people who may have changed their config/database.yml when calling this command?

[gmcgibbon]

Forgot to ask, how are we handling cases where people who may have changed their config/database.yml when calling this command?

The generator will detect a configuration file already exists and gives options to overwrite, show a diff, reject the change, or merge the two files together.

Eg.

rails g db:system:change --to mysql
    conflict  config/database.yml
Overwrite /Users/gannon/dummy/config/database.yml? (enter "h" for help) [Ynaqdhm] h
        Y - yes, overwrite
        n - no, do not overwrite
        a - all, overwrite this and all others
        q - quit, abort
        d - diff, show the differences between the old and the new
        h - help, show this help
        m - merge, run merge tool
Overwrite /Users/gannon/dummy/config/database.yml? (enter "h" for help) [Ynaqdhm]

[gmcgibbon]

I've hidden the change generator, reverted the patch to call it with rails g, and removed the static gemfile strings in favour of template evaluation. Let me know if there's anything else this PR needs to get shipped!

[bogdanvlviv]

Hey, Thanks for adding this!
Since this PR is merged we should close #34710, and #34732?
Also, I think we should exclude db:change from commands (railties/lib/rails/command.rb file) in order to not show it on rails --help, (we should show db:system:change instead).
Sorry for the too late review.

Edited: Seems like Rails::Command::Db::System::ChangeCommand.printing_commands returns ["db:change"] instead of [db:system:change].

[rafaelfranca]

cc @gmcgibbon

[gmcgibbon]

Thanks for pointing that out @bogdanvlviv, I'll see what I can do!