- 31 1月, 2014 1 次提交
-
-
由 Lauro Caetano 提交于
Dangerous association names conflicts include instance or class methods already defined by `ActiveRecord::Base`.
-
- 28 1月, 2014 1 次提交
-
-
由 Carlos Antonio da Silva 提交于
-
- 22 1月, 2014 1 次提交
-
-
由 Jason Meller 提交于
This commit fixes two regressions introduced in cafe31a0 where newly created finder methods #second, #third, #forth, and #fifth caused a NoMethodError error on reload associations and where we were pulling the wrong element out of cached associations. Examples: some_book.authors.reload.second # Before # => NoMethodError: undefined method 'first' for nil:NilClass # After # => #<Author id: 2, name: "Sally Second", ...> some_book.first.authors.first some_book.first.authors.second # Before # => #<Author id: 1, name: "Freddy First", ...> # => #<Author id: 1, name: "Freddy First", ...> # After # => #<Author id: 1, name: "Freddy First", ...> # => #<Author id: 2, name: "Sally Second", ...> Fixes #13783.
-
- 19 12月, 2013 1 次提交
-
-
由 Carlos Antonio da Silva 提交于
Change most tests to make use of assert_raise returning the raised exception rather than relying on a combination of flunk + rescue to check for exception types/messages.
-
- 26 11月, 2013 3 次提交
-
-
由 heruku 提交于
-
由 Brian Thomas Storti 提交于
Fixes #12812 Raise `ActiveRecord::RecordNotDestroyed` when a child marked with `dependent: destroy` can't be destroyed. The following code: ```ruby class Post < ActiveRecord::Base has_many :comments, dependent: :destroy end class Comment < ActiveRecord::Base before_destroy do return false end end post = Post.create!(comments: [Comment.create!]) post.comments = [Comment.create!] ```` would result in a `post` with two `comments`. With this commit, the same code would raise a `RecordNotDestroyed` exception, keeping the `post` with the same `comment`.
-
由 Vipul A M 提交于
-
- 21 11月, 2013 1 次提交
-
-
由 Jon Leighton 提交于
I'm pretty confused about the addition of this method. The documentation says that it was intended to allow the removal of values from the default scope (in contrast to #except). However it behaves exactly the same as except: https://gist.github.com/jonleighton/7537008 (other than having a slightly enhanced syntax). The removal of the default scope is allowed by 94924dc3, which was not a change we could make until 4.1 due to the need to deprecate things. However after that change #unscope still gives us nothing that #except doesn't already give us. However there *is* a desire to be able to unscope stuff in a way that persists across merges, which would allow associations to be defined which unscope stuff from the default scope of the associated model. E.g. has_many :comments, -> { unscope where: :trashed } So that's what this change implements. I've also corrected the documentation. I removed the guide references to #except as I think unscope really supercedes #except now. While we're here, there's also a potential desire to be able to write this: has_many :comments, -> { unscoped } However, it doesn't make sense and would not be straightforward to implement. While with #unscope we're specifying exactly what we want to be removed from the relation, with "unscoped" we're just saying that we want it to not have some things which were added earlier on by the default scope. However in the case of an association, we surely don't want *all* conditions to be removed, otherwise the above would just become "SELECT * FROM comments" with no foreign key constraint. To make the above work, we'd have to somehow tag the relation values which get added when evaluating the default scope in order to differentiate them from other relation values. Which is way too much complexity and therefore not worth it when most use cases can be satisfied with unscope. Closes #10643, #11061.
-
- 17 11月, 2013 1 次提交
-
-
由 Edo Balvers 提交于
-
- 02 11月, 2013 2 次提交
-
-
由 Rafael Mendonça França 提交于
was using nullify strategy This caused a regression in applications trying to upgrade. Also if the user set the dependent option as destroy he expects to get the records removed from the database.
-
由 Rafael Mendonça França 提交于
-
- 29 10月, 2013 1 次提交
-
-
由 David Heinemeier Hansson 提交于
-
- 28 9月, 2013 1 次提交
-
-
由 Paul Nikitochkin 提交于
In order to build associated records for owners which has not been saved need to get where values to use as default attributes. But for new record owner uses `ActiveRecord::NullRelation` which override `where_values_hash` to return empty hash stub. `where_values_hash` is not used to invoke any sql query, but good to build others chains (even will be never executed) like: ```ruby post = Post.new admin_comment = post.admin_comments.build assert_equal 'Admin', admin_comment.author ``` Closes #11376, #11676, #11675
-
- 26 9月, 2013 2 次提交
-
-
由 Arthur Neves 提交于
.find([1]) should return an Array of entries, even when a invese object is in memory already
-
由 Arthur Neves 提交于
-
- 10 9月, 2013 1 次提交
-
-
由 Lann Martin 提交于
When first or last is called with an integer on an unloaded association, the entire collection is loaded. This differs surprisingly from the behavior of Relation#first/last, which translate the call into a limit query. For large collections this can make a big difference in performance. Change CollectionAssociation#fetch_first_or_last_using_find? to make this kind of call delegate to Relation.
-
- 04 9月, 2013 1 次提交
-
-
由 Aaron Patterson 提交于
-
- 30 7月, 2013 1 次提交
-
-
由 Rafael Mendonça França 提交于
order on the old ones The previous behavior added a major backward incompatibility since it impossible to have a upgrade path without major changes on the application code. We are taking the most conservative path to be consistent with the idea of having a smoother upgrade on Rails 4. We are reverting the behavior for what was in Rails 3.x and, if needed, we will implement a new API to prepend the order clauses in Rails 4.1.
-
- 03 7月, 2013 2 次提交
-
-
由 Neeraj Singh 提交于
-
由 Neeraj Singh 提交于
-
- 02 7月, 2013 2 次提交
-
-
由 Neeraj Singh 提交于
-
由 Neeraj Singh 提交于
Deprecated options `delete_sql`, `insert_sql`, `finder_sql` and `counter_sql` have been deleted.
-
- 30 6月, 2013 1 次提交
-
-
由 Neeraj Singh 提交于
Method `delete_all` should not be invoking callbacks and this feature was deprecated in Rails 4.0. This is being removed. `delete_all` will continue to honor the `:dependent` option. However if `:dependent` value is `:destroy` then the default deletion strategy for that collection will be applied. User can also force a deletion strategy by passing parameter to `delete_all`. For example you can do `@post.comments.delete_all(:nullify)`
-
- 24 6月, 2013 2 次提交
-
-
由 Vipul A M 提交于
-
由 Jared Armstrong 提交于
-
- 22 6月, 2013 1 次提交
-
-
由 Yves Senn 提交于
Closes #11026
-
- 18 6月, 2013 1 次提交
-
-
由 Yves Senn 提交于
-
- 01 6月, 2013 1 次提交
-
-
由 kennyj 提交于
-
- 23 5月, 2013 1 次提交
-
-
由 Yves Senn 提交于
When removing records from a `has_many` association it used the `primary_key` defined on the association. Our test suite didn't fail because on all occurences of `:primary_key`, the specified column was available in both tables. This prevented the code from raising an exception but it still behaved badly. I added a test-case to prevent regressions that failed with: ``` 1) Error: HasManyAssociationsTest#test_has_many_assignment_with_custom_primary_key: ActiveRecord::StatementInvalid: SQLite3::SQLException: no such column: essays.first_name: UPDATE "essays" SET "writer_id" = NULL WHERE "essays"."writer_id" = ? AND "essays"."first_name" IS NULL ```
-
- 22 4月, 2013 1 次提交
-
-
由 Matthew Robertson 提交于
This commit fixes a regression bug in which counter_cache columns were not being updated correctly when newly created records were being pushed into an assocation. EG: # this was fine @post.comment.create! # this was fine @comment = Comment.first @post.comments << @comment # this would not update counters @post.comments << Comment.create!
-
- 08 4月, 2013 1 次提交
-
-
由 Dan Erikson 提交于
This makes the arguments the same as ActiveRecord::QueryMethods::select.
-
- 16 3月, 2013 1 次提交
-
-
由 John Wang 提交于
the primary key on an association will make sure that the corresponding counter on the association is changed properly. Fixes #9722.
-
- 25 2月, 2013 1 次提交
-
-
由 Rafael Mendonça França 提交于
-
- 24 2月, 2013 1 次提交
-
-
由 Yves Senn 提交于
closes #9201
-
- 27 1月, 2013 1 次提交
-
-
由 Derek Kraan 提交于
because of an ambiguous column name. This happened if the association model had a default scope that referenced a third table, and the third table also referenced the original table (with an identical foreign_key). Mysql requires that ambiguous columns are deambiguated by using the full table.column syntax. Postgresql and Sqlite use a different syntax for updates altogether (and don't tolerate table.name syntax), so the fix requires always including the full table.column and discarding it later for Sqlite and Postgresql.
-
- 18 1月, 2013 4 次提交
-
-
由 Guillermo Iguaran 提交于
This reverts commit 637a7d9d, reversing changes made to 5937bd02.
-
由 robertomiranda 提交于
-
由 Jon Leighton 提交于
Suggested by @dhh. It doesn't affect the generated SQL, so seems reasonable to continue to allow it as an association option.
-
由 Jon Leighton 提交于
Fixes #8795
-
- 13 1月, 2013 1 次提交
-
-
由 Yves Senn 提交于
-