New `console` option for a "protected" session

rubyonrails-core
1

Whilst it is asking for trouble, many developers (myself included) cannot resist the occasional temptation to drop into a Rails console in a production environment and perform data mods on production data.

In the spirit of the current “sandbox” option available in the Rails console, what do you think about another option that offers a “protected” session, in which:

  • Like “sandbox”, the console session is wrapped in a database transaction, but
  • At the end of the session changes are listed (either summarily in # of changes, or in listed detail) and can be committed or rolled back by “y/n” confirmation Why?

In addition to protecting against ruining production data, it would allow people to inspect and validate the effect of their data mod on production data without having to apply a DB-wide restore from a backup if a mistake is made or changes aren’t what they expect.

The test case in console_test.rb might look like:

def test_protected spawn_console

write_prompt "Post.count", "=> 0"
write_prompt "Post.create"
write_prompt "Post.count", "=> 1"

@master.puts "quit"

assert_output "Commit 1 change? (y/n)"

@master.puts "n"

spawn_console

write_prompt "Post.count", "=> 0"
write_prompt "Post.create"
write_prompt "Post.create"
write_prompt "Post.count", "=> 2"

@master.puts "quit"

assert_output "Commit 2 changes? (y/n)"

@master.puts "y"

spawn_console

write_prompt "Post.count", "=> 2"

end

``

2

It is an interesting idea. It seems like a reasonable safeguard. Usually for this sort of thing, I try to get the actual data, or very similar data, in my local database, and make the changes there. I can restore from a dump file locally over and over if needed. I write a script and deploy it if the change is more than a few lines. The script also serves as documentation for other developers to apply it, or fetch new data from production.

Maybe you could develop this as a gem and try it out in your project, then if you like it, and some people are using it, propose it to Rails. I’d be interested to try it anyway, feel free to ping me if you want someone to kick the tires. :slight_smile: andyatkinson (Andrew Atkinson) · GitHub

3

Wouldn’t this give a false sense of security? What if, as a result of some model changes, something outside of a transaction (say background job) is triggered?