New `console` option for a "protected" session

[Daniel Treacy]

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

[Andy A]

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. :) https://github.com/andyatkinson

[Ed Kim]

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?

--
You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-co...@googlegroups.com.
To post to this group, send email to rubyonra...@googlegroups.com.
Visit this group at http://groups.google.com/group/rubyonrails-core.
For more options, visit https://groups.google.com/d/optout.