- 08 9月, 2015 1 次提交
-
-
由 Matthew Draper 提交于
Generic cast-to-text was only added in 8.3.
-
- 07 9月, 2015 2 次提交
-
-
由 Tobias Bielohlawek 提交于
-
由 Yves Senn 提交于
-
- 06 9月, 2015 2 次提交
-
-
由 Wojciech Wnętrzak 提交于
-
由 Grey Baker 提交于
See http://www.postgresql.org/docs/9.4/static/sql-dropindex.html for more details.
-
- 28 8月, 2015 2 次提交
- 24 8月, 2015 1 次提交
-
-
由 Agis- 提交于
Since after 87d1aba3 `dependent: :destroy` callbacks on has_one assocations run *after* destroy, it is possible that a nullification is attempted on an already destroyed target: class Car < ActiveRecord::Base has_one :engine, dependent: :nullify end class Engine < ActiveRecord::Base belongs_to :car, dependent: :destroy end > car = Car.create! > engine = Engine.create!(car: car) > engine.destroy! # => ActiveRecord::ActiveRecordError: cannot update a > destroyed record In the above case, `engine.destroy!` deletes `engine` and *then* triggers the deletion of `car`, which in turn triggers a nullification of `engine.car_id`. However, `engine` is already destroyed at that point. Fixes #21223.
-
- 20 8月, 2015 1 次提交
-
-
由 Yves Senn 提交于
Closes #21304. While we can validate uniqueness for record without primary key on creation, there is no way to exclude the current record when updating. (The update itself will need a primary key to work correctly).
-
- 18 8月, 2015 1 次提交
-
-
由 Ryuta Kamizono 提交于
As of MySQL 5.7.8, MySQL supports a native JSON data type. Example: create_table :json_data_type do |t| t.json :settings end
-
- 13 8月, 2015 1 次提交
-
-
由 Yves Senn 提交于
Closes #21201.
-
- 07 8月, 2015 2 次提交
-
-
由 Zachary Scott 提交于
This includes the following classes: - ActiveModel::Serializers::Xml - ActiveRecord::Serialization::XmlSerializer
-
由 Sina Siadat 提交于
`in_batches` yields Relation objects if a block is given, otherwise it returns an instance of `BatchEnumerator`. The existing `find_each` and `find_in_batches` methods work with batches of records. The new API allows working with relation batches as well. Examples: Person.in_batches.each_record(&:party_all_night!) Person.in_batches.update_all(awesome: true) Person.in_batches.delete_all Person.in_batches.map do |relation| relation.delete_all sleep 10 # Throttles the delete queries end
-
- 02 8月, 2015 1 次提交
-
-
由 starbelly 提交于
- Added run_cmd() class method to dry up Kernel.system() messages within this namespace and avoid shell expansion by passing a list of arguments instead of a string - Update structure_dump, structure_load, and related tests units to pass a list of params instead of using a string to avoid shell expansion
-
- 01 8月, 2015 1 次提交
-
-
由 Yves Senn 提交于
-
- 26 7月, 2015 1 次提交
-
-
由 Sean Griffin 提交于
This is an alternate implementation of #20966. [Sean Griffin & presskey]
-
- 24 7月, 2015 1 次提交
-
-
由 Sean Griffin 提交于
Deep down in the association internals, we're calling `destroy!` rather than `destroy` when handling things like `dependent` or autosave association callbacks. Unfortunately, due to the structure of the code (e.g. it uses callbacks for everything), it's nearly impossible to pass whether to call `destroy` or `destroy!` down to where we actually need it. As such, we have to do some legwork to handle this. Since the callbacks are what actually raise the exception, we need to rescue it in `ActiveRecord::Callbacks`, rather than `ActiveRecord::Persistence` where it matters. (As an aside, if this code wasn't so callback heavy, it would handling this would likely be as simple as changing `destroy` to call `destroy!` instead of the other way around). Since we don't want to lose the exception when `destroy!` is called (in particular, we don't want the value of the `record` field to change to the parent class), we have to do some additional legwork to hold onto it where we can use it. Again, all of this is ugly and there is definitely a better way to do this. However, barring a much more significant re-architecting for what I consider to be a reletively minor improvement, I'm willing to take this small hit to the flow of this code (begrudgingly).
-
- 23 7月, 2015 1 次提交
-
-
由 Robin Dupret 提交于
This makes it more clear that they are reserved keywords and also it seems less redundant as the line already starts with the call to the `enum` method.
-
- 21 7月, 2015 2 次提交
-
-
由 Sameer Rahmani 提交于
ActiveRecord::RecordNotFound modified to store model name, primary_key and id of the caller model. It allows the catcher of this exception to make a better decision to what to do with it. For example consider this simple example: class SomeAbstractController < ActionController::Base rescue_from ActiveRecord::RecordNotFound, with: :redirect_to_404 private def redirect_to_404(e) return redirect_to(posts_url) if e.model == 'Post' raise end end
-
由 Roque Pinel 提交于
Previously `has_one` and `has_many` associations were using the `one` and `many` keys respectively. Both of these keys have special meaning in I18n (they are considered to be pluralizations) so by renaming them to `has_one` and `has_many` we make the messages more explicit and most importantly they don't clash with linguistical systems that need to validate translation keys (and their pluralizations). The `:'restrict_dependent_destroy.one'` key should be replaced with `:'restrict_dependent_destroy.has_one'`, and `:'restrict_dependent_destroy.many'` with `:'restrict_dependent_destroy.has_many'`. [Roque Pinel & Christopher Dell]
-
- 20 7月, 2015 4 次提交
-
-
由 Roque Pinel 提交于
This clears the transaction record state when the transaction finishes with a `:committed` status. Considering the following example where `name` is a required attribute. Before we had `new_record?` returning `true` for a persisted record: ```ruby author = Author.create! name: 'foo' author.name = nil author.save # => false author.new_record? # => true ```
-
由 Sean Griffin 提交于
As per the docs, `mark_for_destruction` should do nothing if `autosave` is not set to true. We normally persist associations on a record no matter what if the record is a new record, but we were always skipping records which were `marked_for_destruction?`. Fixes #20882
-
由 Alberto F. Capel 提交于
-
由 Stefan Kanev 提交于
Also removes a false positive test that depends on the fixed bug: At this time, counter_cache does not work with polymorphic relationships (which is a bug). The test was added to make sure that no StaleObjectError is raised when the car is destroyed. No such error is currently raised because the lock version is not incremented by appending a wheel to the car. Furthermore, `assert_difference` succeeds because `car.wheels.count` does not check the counter cache, but the collection size. The test will fail if it is replaced with `car.wheels_count || 0`.
-
- 18 7月, 2015 4 次提交
-
-
由 Sean Griffin 提交于
This code is so fucked. Things that cause this bug not to replicate: - Defining the validation before the association (we end up calling `uniq!` on the errors in the autosave validation) - Adding `accepts_nested_attributes_for` (I have no clue why. The only thing it does that should affect this is adds `autosave: true` to the inverse reflection, and doing that manually doesn't fix this). This solution is a hack, and I'm almost certain there's a better way to go about it, but this shouldn't cause a huge hit on validation times, and is the simplest way to get it done. Fixes #20874.
-
由 Sean Griffin 提交于
Since nested hashes are also instances of `ActionController::Parameters`, and we're explicitly looking to work with a hash for nested attributes, this caused breakage in several points. This is the minimum viable fix for the issue (and one that I'm not terribly fond of). I can't think of a better place to handle this at the moment. I'd prefer to use some sort of solution that doesn't special case AC::Parameters, but we can't use something like `to_h` or `to_a` since `Enumerable` adds both. While I've added a trivial test case for verifying this fix in isolation, we really need better integration coverage to prevent regressions like this in the future. We don't actually have a lot of great places for integration coverage at the moment, so I'm deferring it for now. Fixes #20922.
-
由 Peter Boling 提交于
- CR feedback from @egilburg Additionally - Move logic for colorizing the payload name into a separate method - Make some `ActiveRecord::LogSubscriber` instance methods private for clarity: - `colorize_payload_name` - `sql_color` - `logger` - Improve Changelog Documentation GH #20885
-
由 Peter Boling 提交于
- Improves coloring for statements like: # Become WHITE SELECT * FROM ( SELECT * FROM mytable FOR UPDATE ) ss WHERE col1 = 5; LOCK TABLE table_name IN ACCESS EXCLUSIVE MODE; # Becomes RED ROLLBACK - Reinstates the coloration of the `payload[:name]`. Instead of simple alternating colors, adds meaning: - `MAGENTA` for `"SQL"` or `blank?` payload names - `CYAN` for Model Load/Exists - Introduces specs for sql coloration. - Introduces specs for payload name coloration. GH#20885
-
- 16 7月, 2015 1 次提交
-
-
由 Prem Sichanugrist 提交于
This is to simplify the association API, as you can call `reload` on the association proxy or the parent object to get the same result. For collection association, you can call `#reload` on association proxy to force a reload: @user.posts.reload # Instead of @user.posts(true) For singular association, you can call `#reload` on the parent object to clear its association cache then call the association method: @user.reload.profile # Instead of @user.profile(true) Passing a truthy argument to force association to reload will be removed in Rails 5.1.
-
- 14 7月, 2015 1 次提交
-
-
由 Jerry D'Antonio 提交于
The concurrent-ruby gem is a toolset containing many concurrency utilities. Many of these utilities include runtime-specific optimizations when possible. Rather than clutter the Rails codebase with concurrency utilities separate from the core task, such tools can be superseded by similar tools in the more specialized gem. This commit replaces `ActiveSupport::Concurrency::Latch` with `Concurrent::CountDownLatch`, which is functionally equivalent.
-
- 07 7月, 2015 1 次提交
-
-
由 Dmitry Zudochkin 提交于
-
- 01 7月, 2015 1 次提交
-
-
由 Sean Griffin 提交于
The changes introduced to through associations in c80487eb were quite interesting. Changing `relation.merge!(scope)` to `relation = relation.merge(scope)` should in theory never cause any changes in behavior. The subtle breakage led to a surprising conclusion. The old code wasn't doing anything! Since `merge!` calls `instance_exec` when given a proc, and most scopes will look something like `has_many :foos, -> { where(foo: :bar) }`, if we're not capturing the return value, it's a no-op. However, removing the `merge` causes `unscope` to break. While we're merging in the rest of the chain elsewhere, we were never merging in `unscope` values, causing a breakage on associations where a default scope was being unscoped in an association scope (yuk!). This is subtly related to #20722, since it appears we were previously relying on this mutability. Fixes #20721. Fixes #20727.
-
- 30 6月, 2015 1 次提交
-
-
由 Yves Senn 提交于
Closes #20743. The task `db:_dump` now only dumps the schema if `ActiveRecord::Base.dump_schema_after_migration` is true. This has effects: - `db:migrate:up` - `db:migrate:down` - `db:forward` - `db:rollback`
-
- 27 6月, 2015 1 次提交
-
-
由 Prem Sichanugrist 提交于
Passing `:from` and `:to` to `change_column_default` makes this command reversible as user has defined its previous state. So, instead of having the migration command as: change_column_default(:posts, :state, "draft") They can write it as: change_column_default(:posts, :state, from: nil, to: "draft")
-
- 22 6月, 2015 2 次提交
-
-
由 Diego Carrion 提交于
thrown ActiveRecord::AssociationTypeMismatch when assigning a wrong value for a namespaced association fixes #20541
-
由 Yves Senn 提交于
Associated objects that were marked for destruction are considered absent.
-
- 20 6月, 2015 2 次提交
-
-
由 Sean Griffin 提交于
After discussing, we've decided it makes more sense to include it. We're already forwarding every conflicting method to `to_a`, and there's no conflation of concerns. `Enumerable` has no mutating methods, and it just allows us to simplify the code. No existing methods will have a change in behavior. Un-overridden Enumerable methods will simply delegate to `each`. [Sean Griffin & bogdan]
-
由 Sean Griffin 提交于
This matches our behavior in other cases where useful enumerable methods might have a different definition in `Relation`. Wanting to actually enumerate over the records in this case is completely reasonable, and wanting `.sum` is reasonable for the same reason it is on `Enumerable` in the first place.
-
- 15 6月, 2015 2 次提交