| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously, when `time_zone_aware_attributes` were enabled, after
changing a datetime or timestamp attribute and then changing it back
to the original value, `changed_attributes` still tracked the
attribute as changed. This caused `[attribute]_changed?` and
`changed?` methods to return true incorrectly.
Example:
in_time_zone 'Paris' do
order = Order.new
original_time = Time.local(2012, 10, 10)
order.shipped_at = original_time
order.save
order.changed? # => false
# changing value
order.shipped_at = Time.local(2013, 1, 1)
order.changed? # => true
# reverting to original value
order.shipped_at = original_time
order.changed? # => false, used to return true
end
|
| |\ \
| | |
| | |
| | |
| | |
| | | |
Conflicts:
actionpack/lib/action_view/helpers/form_options_helper.rb
guides/code/getting_started/app/controllers/comments_controller.rb
|
| | | | |
|
| | | |
| | |
| | |
| | | |
I think that these signs are probably mistake.
|
| | | | |
|
| | | |
| | |
| | |
| | | |
closes #6865
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
or the ConnectionPool silently fails to close connections inside the Thread
|
| | | |
| | |
| | |
| | | |
Travis only has PostgreSQL 9.1.x but 9.2 is required for range datatypes.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This reverts commit e9d2ad395ec2ef929d74752f3d71c80674044fbe.
Closes #8460
Conflicts:
activerecord/lib/active_record/attribute_methods/time_zone_conversion.rb
activerecord/test/cases/dirty_test.rb
|
| | | |
| | |
| | |
| | | |
[ci skip]
|
| | | | |
|
| | | | |
|
| | | | |
|
| | |/
|/|
| |
| | |
new transaction state object upon initialization.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
* User class instead of Users.
* #where_values_hash does not change the value to downcase as the
example was showing.
[ci skip]
|
| |\ \
| | |
| | | |
Fix .update_all and .delete_all when using a condition on a joined table in a default_scope
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
in a default_scope.
`Model.joins(...).where(condition_on_joined_table).update_all` /
`delete_all` worked, but the same operation implemented with a
default_scope generated a SQL error because ActiveRecord ignored the
join but implemented the where condition anyways.
|
| | | |
| | |
| | |
| | |
| | | |
This reverts commit 637a7d9d357a0f3f725b0548282ca8c5e7d4af4a, reversing
changes made to 5937bd02dee112646469848d7fe8a8bfcef5b4c1.
|
| |\ \ \
| | | |
| | | | |
Replace deprecated find_by_* with find_by
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Suggested by @dhh.
It doesn't affect the generated SQL, so seems reasonable to continue to
allow it as an association option.
|
| | | | |
| | | |
| | | |
| | | | |
Fixes #8795
|
| |\ \ \ \
| | | | |
| | | | | |
`CollectionAssociation#empty?` respects newly builded records
|
| | | | | | |
|
| | |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This revision makes crystal clear that the methods go
straight to the database and update the receiver. It
also adds and example, and removes the duplication
in the singular and plural forms by referring one to
the other.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
There's no need to create a new arel table or reflect on the column
association if the value is empty, these attributes are not used.
Also no need to concat a new array, just append the query value.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
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.
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This reverts commit 8348f9ea72c9b50fc4d4462fd9ebe3bba932c783, reversing
changes made to 9dfe2d6f9fabddf9a451a995678a9648c8aaf401.
Reason: this broke railties tests as explained in the issue, and the
author is going to review and report back.
https://github.com/rails/rails/pull/8930#issuecomment-12272671
|
| |\ \ \ \
| | | | |
| | | | | |
rake railties:install:migrations respects the order of railties
|
| | |/ / / |
|
| |/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
exception
We were previously rescuing "nil" when no exception class was found.
This does work in 1.9.3, but does not in 2.0, raising an exception
asking for a class or module to be given to the rescue clause.
Thanks @yahonda for catching this.
|
| | | | |
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When running tasks such "rake db:setup", instead of showing messages
like "db_development already exists", it was showing a big stack trace
and a message "Couldn't create database for ..." with the configuration
options, a very confusing message with a big trace.
This brings back the functionality present in 3-2, showing the same
message.
|
| |\ \
| | |
| | | |
Correct source for in_clause_length for eager loading (Fix for #8474)
|
| | | |
| | |
| | |
| | | |
(fixes #8474)
|
| |\ \ \
| | | |
| | | | |
Refactor target_reflection_has_associated_record?
|
| | | | | |
|
| |\ \ \ \
| |_|_|/
|/| | | |
Improved different_target conditions
|
| | |/ / |
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
Conflicts:
guides/source/getting_started.md
|
| | | | | |
|
| | | | |
| | | |
| | | |
| | | | |
particularly, `all(options)` would warn
|
| | | | | |
|
| | | | | |
|
