When then PostgreSQL visitor was [added](6b7fdf3bf3)
`add_column` was no longer receiving the column options directly. This
caused the options to be lost along the way.
This behaviour doesn't actually make sense, the context of
the child should not be affected by the parent. See #10492.
This reverts commit 5f8274efe128ffeec8fa3179460f5167a078f007, reversing
changes made to 81e837e810460d066a2e5fc5a795366ec8ab2313.
* Inspect uses double quotes.
* Inspect puts a hash as in #<User ...>.
* Documents the return value, and makes explicit it can be an invalid record.
* Documents the method is not atomic.
* Documents a way to handle UNIQUE contraint violations in the event of a race condition.
* Removes the "Examples" header according to our guidelines.
* It is no longer true that options are passed to find.
* Documents that ActiveRecord::RecordNotFound may be raised.
* Documents that the reload happens in-place.
* Documents that caches are wiped.
* Documents that the method returns self.
* Documents a couple of use cases.
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
```
* bindwhere:
avoid creating a set if no where values are removed
remove bind values for where clauses that were removed
push partitioning up so bind elimination can get the removed wheres
push partion logic down and initialization logic up
partition the where values so we can access the removed ones
Due to commit 0123c39f41e2062311b2197e6e230ef8ad67e20e, column
topic.unique_replies_count has been added, and these test started to
fail since the tests depends on the topic tables column info.
in myself, a column with type TINYINT(N) where N > 1 can be used to
represent an integer, but the rails mysql adapter refuses to interpret
as anything but a boolean.
* master: (61 commits)
add tests for reset_calbacks
Fixing build broken by this change
Extract variable out of loop
Updated comment to Rails 4
Fixes NoMethodError: `alias_method_chain` when requiring just active_support/core_ext
better error message when app name is not passed in `rails new`
Code cleanup for ActionDispatch::Flash#call
Fix typo: require -> requires
Add CHANGELOG entry for #10576
Merge pull request #10556 from Empact/deprecate-schema-statements-distinct
Some editorial changes on the documentation.
respond_to -> respond to in a message from AM::Lint
specify that dom_(id|class) are deprecated in controllers, views are fine
copy edits [ci skip]
Fix class and method name typos
Replace multi_json with json
ruby -> Ruby
Adding documentation to the automatic inverse_of finder.
Improve CHANGELOG entry [ci kip]
Call assume_migrated_upto_version on connection
...
Conflicts:
activesupport/lib/active_support/callbacks.rb
Cleaned up rdoc a bit emphasizing that callbacks are called. Also
removed the stress on the fact that records are always removed.
If callbacks return false then records will not be deleted.
Call assume_migrated_upto_version on connection to prevent it from first
being picked up in method_missing. In the base class, Migration,
method_missing expects the argument to be a table name, and calls
proper_table_name on the arguments before sending to connection. If
table_name_prefix or table_name_suffix is used, the schema version changes
to prefix_version_suffix, breaking `rake test:prepare`.
Fixes#10411.
This will help avoid errors like 2fcafee250ee2, because in most cases NullRelation will do the right thing. Minor bonus is avoiding the use of exceptions for flow control.
The combination of a :uniq => true association and the #distinct call
in #construct_limited_ids_condition combine to create invalid SQL, because
we're explicitly selecting DISTINCT, and also sending #distinct on to AREL,
via the relation#distinct_value.
Rather than build a select distinct clause in #construct_limited_ids_condition,
I set #distinct! and pass just the columns into the select statement.
This requires introducing a #columns_for_distinct method to return the
select columns but not the statement itself.
Suppose Man has_many interests, and inverse_of is used.
Man.first.interests.first.man will correctly execute two queries,
avoiding the need for a third query when Interest#man is called. This is
because CollectionAssociation#first calls set_inverse_instance.
However Man.first.interests.where("1=1").first.man will execute three
queries, even though this is obviously a subset of the records in the
association.
This is because calling where("1=1") spawns a new Relation object from
the CollectionProxy object, and the Relation has no knowledge of the
association, so it cannot set the inverse instance.
This commit solves the problem by making relations spawned from
CollectionProxies return a new Relation subclass called
AssociationRelation, which does know about associations. Records loaded
from this class will get the inverse instance set properly.
Fixes#5717.
Live commit from La Conf! ✨
In order to fix#10421 I need to enable merge to take an option
so that relations could be merged without making the last where
condition to win.
That fix would forever reside in 4-0-stable branch and would not be
merged to master since using scope without lambda has been deprecated.
In this commit I have extracted code into a method and I think it
makes code look better. Hence the request to merge it in both
master and 4-0-stable.
If there is any concern then this code can be merged only in
4-0-stable and that would be fine too.
the results. Added tests to check to make sure that inverse associations are
automatically found when has_many, has_one, or belongs_to associations
are defined.
Because of each adapter implementation differences,
`expected_value` string needed to be handled by each adapter.
This commit removes current_adapter
by using ActiveRecord::ConnectionAdapters::Quoting methods.
In #10410 it was noted that you can no longer create PK's with the
type of bigserial in PostgreSQL in 4.0.0.rc1. This is mostly
because the newer adapter is checking for column type with the
id column instead of just letting it pass through like it did
before.
Side effects:
You may just create a PK column of a type that you really don't
want to be your PK. As far as I can tell this was allowed in 3.2.X
and perhaps an exception should be raised if you try and do
something extremely dumb.
counter cache
At present, calling destroy multiple times on the same record results
in the belongs_to counter cache being decremented multiple times. With
this change the record is checked for whether it is already destroyed
prior to decrementing the counter cache.
fixes#10419
Following code should raise IrreversibleMigration. But the code was
failing since options is an array and not a hash.
def change
change_table :users do |t|
t.remove_index [:name, :email]
end
end
Fix was to check if the options is a Hash before operating on it.
Warning was: "/vagrant/rails/activerecord/test/cases/adapters/postgresql/uuid_test.rb:63:
warning: ambiguous first argument; put parentheses or even spaces"
For one-to-one nested associations, if you build the new (in-memory)
child object yourself before assignment, then the NestedAttributes
module will not overwrite it, e.g.:
class Member < ActiveRecord::Base
has_one :avatar
accepts_nested_attributes_for :avatar
def avatar
super || build_avatar(width: 200)
end
end
member = Member.new
member.avatar_attributes = {icon: 'sad'}
member.avatar.width # => 200
test_mysql_integer_not_null_defaults in test/cases/defaults_test.rb was
failing. This test relies on the connection being in strict mode. By
default a new connection is not in strict mode, but Active Record
automatically places it in strict mode.
ActiveSchemaTest overwrites the connection's #execute method in order to
prevent SQL statements from actually being executed. One of the
operations which is performed in ActiveSchema test is a #recreate_database.
Since 2088bf27981137a2c6c8b2f718f33b417b4045af, recreate_database on
mysql or mysql2 will trigger a reconnect.
Due to the implementation of the hacking of #execute in
ActiveSchemaTest, this reconnect would take place, but the connection
would *not* be placed in strict mode because #execute had been
overridden to prevent SQL queries hitting the database.
Therefore, after ActiveSchemaTest, the connection would no longer be in
strict mode, causing test_mysql_integer_not_null_defaults to fail.
I don't think that the way that ActiveSchemaTest is implemented is
particularly nice or clean, but I have taken steps to make its hacks
more isolated - it now create a separate connection object which is
thrown away after the test, and the hacks are applied on the singleton
class of this object.
fixes bug introduced by #3329
These are the conditions necessary to reproduce the bug:
- For an association, autosave => true.
- An association record is being destroyed
- A new association record is being created.
- There is a unique index one of the association's fields.
- The record being created has the same value as the record being
destroyed on the indexed field.
Before, the deletion of records was postponed until after all
insertions/saves. Therefore the new record with the identical value in
the indexed field caused a non-unique value error to be thrown at the database
level.
With this fix, the deletions happen first, before the insertions/saves.
Therefore the record with the duplicate value is gone from the database
before the new record is created, thereby avoiding the non-uniuqe value
error.
When using symbol keys, ActiveRecord will now translate aliased attribute names to the actual column name used in the database:
With the model
class Topic
alias_attribute :heading, :title
end
The call
Topic.where(heading: 'The First Topic')
should yield the same result as
Topic.where(title: 'The First Topic')
This also applies to ActiveRecord::Relation::Calculations calls such as `Model.sum(:aliased)` and `Model.pluck(:aliased)`.
This will not work with SQL fragment strings like `Model.sum('DISTINCT aliased')`.
Github #7839
*Godfrey Chan*
activerecord/lib/active_record/associations.rb states:
# [association=(associate)]
# Assigns the associate object, extracts the primary key, sets it as the foreign key,
# and saves the associate object.
Since commit 42dd5d9f2976677a4bf22347f2dde1a8135dfbb4 to fix#7191, this
is no longer the case if the associate has changed, but is the same
object. For example:
# Pirate has_one :ship
pirate = Pirate.create!(catchphrase: "A Pirate")
ship = pirate.build_ship(name: 'old name')
ship.save!
ship.name = 'new name'
pirate.ship = ship
That last line should trigger a save. Although we are not changing the
association, the associate (ship) has changed.
It's simpler to assume that passed env is just a string without any
extensions, especially when DatabaseTasks are intended to be used also
without rails.
This is a public class, which could be used directly in order to allow
easier database management. Now it also contains settings, which will be
used by databases.rake.
Trying to lookup the parent class when the association is being built
runs the risk of generating uninitialized constant errors because
classes haven't been fully defined yet. To work around this we look up
the class at runtime through the `association` method.
Fixes#10197.
