diff options
author | Vitor Baptista <vitor@vitorbaptista.com> | 2013-01-15 23:19:02 -0300 |
---|---|---|
committer | Vitor Baptista <vitor@vitorbaptista.com> | 2013-01-16 10:43:30 -0300 |
commit | e1e5f3005705b3028ca3a09c61444a8c21398273 (patch) | |
tree | 5043b96a180cbe485f99d89bb7fd703bc6324c96 /tasks | |
parent | e5f5863e86a93d8eea503fb36127e7ebe7364f5e (diff) | |
download | rails-e1e5f3005705b3028ca3a09c61444a8c21398273.tar.gz rails-e1e5f3005705b3028ca3a09c61444a8c21398273.tar.bz2 rails-e1e5f3005705b3028ca3a09c61444a8c21398273.zip |
Don't rely on Hash key's ordering
If we set encoding latin1 for a PostgreSQL database, it calls
PostgreSQLAdapter::create_database with options that have,
among other things:
{ 'encoding' => 'latin1' }
Then, we use reverse_merge(:encoding => "utf8") to setup the default
encoding. In the end, the hash looks like:
{ :encoding => 'utf8', 'encoding' => 'latin1' }
The call to options.symbolize_keys calls to_sym on each_key of this
Hash. It usually means that the encoding passed overwrites the default
utf8, but it's not guaranteed. So, we shouldn't rely on it.
The same was happening in ActiveRecord::ConnectionHandling.
Diffstat (limited to 'tasks')
0 files changed, 0 insertions, 0 deletions