| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|\
| |
| |
| | |
Add charset and collation options support for MySQL string and text columns.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
columns
Example:
create_table :foos do |t|
t.string :string_utf8_bin, charset: 'utf8', collation: 'utf8_bin'
t.text :text_ascii, charset: 'ascii'
end
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
As described here https://github.com/rails/rails/issues/19420. When
using the Postgres BigInt[] field type the big int value was not being
translated into schema.rb. This caused the field to become just a
regular integer field when building off of schema.rb. This fix will
address this by delegating the limit from the subtype to the Array type.
https://github.com/rails/rails/issues/19420
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If there was a polymorphic hm:t association with a scope AND second
non-scoped hm:t association on a model the polymorphic scope would leak
through into the call for the non-polymorhic hm:t association.
This would only break if `hotel.drink_designers` was called before
`hotel.recipes`. If `hotel.recipes` was called first there would be
no problem with the SQL.
Before (employable_type should not be here):
```
SELECT COUNT(*) FROM "drink_designers" INNER JOIN "chefs" ON
"drink_designers"."id" = "chefs"."employable_id" INNER JOIN
"departments" ON "chefs"."department_id" = "departments"."id" WHERE
"departments"."hotel_id" = ? AND "chefs"."employable_type" = ?
[["hotel_id", 1], ["employable_type", "DrinkDesigner"]]
```
After:
```
SELECT COUNT(*) FROM "recipes" INNER JOIN "chefs" ON "recipes"."chef_id"
= "chefs"."id" INNER JOIN "departments" ON "chefs"."department_id" =
"departments"."id" WHERE "departments"."hotel_id" = ? [["hotel_id", 1]]
```
From the SQL you can see that `employable_type` was leaking through when
calling recipes. The solution is to dup the chain of the polymorphic
association so it doesn't get cached. Additionally, this follows
`scope_chain` which dup's the `source_reflection`'s `scope_chain`.
This required another model/table/relationship because the leak only
happens on a hm:t polymorphic that's called before another hm:t on the
same model.
I am specifically testing the SQL here instead of the number of records
becasue the test could pass if there was 1 drink designer recipe for the
drink designer chef even though the `employable_type` was leaking through.
This needs to specifically check that `employable_type` is not in the SQL
statement.
|
|
|
|
|
| |
We've replaced most querues using DROP TABLE in our tests already.
This patch replaces the last couple calls.
|
|\
| |
| |
| |
| | |
rebyn/fix/17161-remove-objs-from-has_many-updates-fields
Add specs for adding-to/clear has_many collections’s behavior on `updated_at`
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
There are behaviors mentioned in #17161 that:
1. are not documented properly, and
2. don't have specs
This commit addresses the spec absence. For has_many collections,
1. addition (<<) should update the associated object's updated_at (if any)
2. .clear, depending on options[:dependent], calls delete_all, destroy_all, or nullifies the associated object(s)' foreign key.
|
| |
| |
| |
| | |
`postgresql_xml_data_type` table is used from nowhere.
|
| | |
|
| |
| |
| |
| |
| | |
Lowercase raw SQL has been replaced by 07b659c already. This commit
replaces everything else of raw SQL.
|
| |
| |
| |
| | |
onwards.
|
|\ \
| | |
| | | |
Fix STI for fixtures from multi-files
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
- Add check for not deleting previously created fixtures, to overcome sti fixtures from multiple files
- Added fixtures and fixtures test to verify the same
- Fixed wrong fixtures duplicating data insertion in same table
|
|/ /
| |
| |
| |
| |
| |
| |
| | |
These callbacks will already have been defined when the association was
built. The check against `reflection.autosave` happens at call time, not
at define time, so simply modifying the reflection is sufficient.
Fixes #18704
|
| | |
|
| |
| |
| |
| |
| |
| | |
Update SecureToken Docs
Add Changelog entry for has_secure_token [ci skip]
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
To be possible to use a custom column name to save/read the polymorphic
associated type in a has_many or has_one polymorphic association, now users
can use the option :foreign_type to inform in what column the associated object
type will be saved.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
This is a follow up to https://github.com/rails/rails/commit/07786c5e75a7b0afdf318063510af6b475e3e04c
and https://github.com/rails/rails/commit/cd2596f55e88fe659592612a793c4f4aa723c9be
|
| | |
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In practical terms, this allows serialized columns and tz aware columns
to be used in wheres that go through joins, where they previously would
not behave correctly. Internally, this removes 1/3 of the cases where we
rely on Arel to perform type casting for us.
There were two non-obvious changes required for this. `update_all` on
relation was merging its bind values with arel's in the wrong order.
Additionally, through associations were assuming there would be no bind
parameters in the preloader (presumably because the where would always
be part of a join)
[Melanie Gilman & Sean Griffin]
|
|/
|
|
| |
We were relying on hash inequality in tests
|
|
|
|
|
| |
This fixes <"SQLite3::SQLException: no such column: legacy_things.person_id: SELECT \"legacy_things\".* FROM \"legacy_things\" WHERE \"legacy_things\".\"person_id\" = ?">
in OptimisticLockingTest#test_lock_destroy
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
with dynamic conditions.
Fixes #16128
This bug was introduced in https://github.com/rails/rails/commit/c35e438620f2d56562251571377995359546393d
so it's present from 4.1.2-rc1 and after.
https://github.com/rails/rails/commit/c35e438620f2d56562251571377995359546393d
merges any relation scopes passed as proc objects to the relation,
but does *not* take into account the arity of the lambda.
To reproduce: https://gist.github.com/Agis-/5f1f0d664d2cd08dfb9b
|
|
|
|
|
|
|
| |
As per discussion, this changes the model generators to specify
`null: false` for timestamp columns. A warning is now emitted if
`timestamps` is called without a `null` option specified, so we can
safely change the behavior when no option is specified in Rails 5.
|
| |
|
|
|
|
| |
by using shorter attribute names.
|
|
|
|
| |
This reverts commit e84799d, e31104c and e6ca8e2
|
|
|
|
|
|
| |
This was previously fixed in e84799d but broken in 3f596f8. This commit
reintroduced the conditional that prevents the foreign keys from being
added to MySQL databases.
|
| |
|
| |
|
|
|
|
|
|
| |
The name of the foreign key is not relevant from a users perspective.
Using random names resolves the urge to rename the foreign key when the
respective table or column is renamed.
|
|
|
|
|
|
|
|
|
|
|
| |
Reliant on https://github.com/rails/rails/pull/15747 but pulled to a
separate PR to reduce noise. `has_many :through` associations have the
undocumented behavior of automatically detecting counter caches.
However, the way in which it does so is inconsistent with counter caches
everywhere else, and doesn't actually work consistently.
As with normal `has_many` associations, the user should specify the
counter cache on the `belongs_to`, if they'd like it updated.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
namespaced model
Now the following case will work fine
class Tag < ActiveRecord::Base
end
class Publisher::Article < ActiveRecord::Base
has_and_belongs_to_many :tags
end
Fixes #15761
|
|\
| |
| | |
prevent bad automatic inverse_of association
|
| |
| |
| |
| | |
reflecting on wrong association
|
| |
| |
| |
| |
| |
| |
| | |
This reverts commit dd3ea17191e316aeebddaa7b176f6cfeee7a6365 and add a
regression test.
Fixes #15418
|
| | |
|
| | |
|
| | |
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As a result of all of the refactoring that's been done, it's now
possible for us to define a public API to allow users to specify
behavior. This is an initial implementation so that I can work off of it
in smaller pieces for additional features/refactorings.
The current behavior will continue to stay the same, though I'd like to
refactor towards the automatic schema detection being built off of this
API, and add the ability to opt out of automatic schema detection.
Use cases:
- We can deprecate a lot of the edge cases around types, now that there
is an alternate path for users who wish to maintain the same behavior.
- I intend to refactor serialized columns to be built on top of this
API.
- Gem and library maintainers are able to interact with `ActiveRecord`
at a slightly lower level in a more stable way.
- Interesting ability to reverse the work flow of adding to the schema.
Model can become the single source of truth for the structure. We can
compare that to what the database says the schema is, diff them, and
generate a migration.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* * *
This bug can be triggered when serializing record R (the instance) of type C
(the class), provided that the following conditions are met:
1. The name of one or more columns/attributes on C/R matches an existing private
method on C (e.g. those defined by `Kernel`, such as `format`).
2. The attribute methods have not yet been generated on C.
In this case, the matching private methods will be called by the serialization
code (with no arguments) and their return values will be serialized instead. If
the method requires one or more arguments, it will result in an `ArgumentError`.
This regression is introduced in d1316bb.
* * *
Attribute methods (e.g. `#name` and `#format`, assuming the class has columns
named `name` and `format` in its database table) are lazily defined. Instead of
defining them when a the class is defined (e.g. in the `inherited` hook on
`ActiveRecord::Base`), this operation is deferred until they are first accessed.
The reason behind this is that is defining those methods requires knowing what
columns are defined on the database table, which usually requires a round-trip
to the database. Deferring their definition until the last-possible moment helps
reducing unnessary work, especially in development mode where classes are
redefined and throw away between requests.
Typically, when an attribute is first accessed (e.g. `a_book.format`), it will
fire the `method_missing` hook on the class, which triggers the definition of
the attribute methods. This even works for methods like `format`, because
calling a private method with an explicit receiver will also trigger that hook.
Unfortunately, `read_attribute_for_serialization` is simply an alias to `send`,
which does not respect method visibility. As a result, when serializing a record
with those conflicting attributes, the `method_missing` is not fired, and as a
result the attribute methods are not defined one would expected.
Before d1316bb, this is negated by the fact that calling the `run_callbacks`
method will also trigger a call to `respond_to?`, which is another trigger point
for the class to define its attribute methods. Therefore, when Active Record
tries to run the `after_find` callbacks, it will also define all the attribute
methods thus masking the problem.
* * *
The proper fix for this problem is probably to restrict `read_attribute_for_serialization`
to call public methods only (i.e. alias `read_attribute_for_serialization` to
`public_send` instead of `send`). This however would be quite risky to change
in a patch release and would probably require a full deprecation cycle.
Another approach would be to override `read_attribute_for_serialization` inside
Active Record to force the definition of attribute methods:
def read_attribute_for_serialization(attribute)
self.class.define_attribute_methods
send(attribute)
end
Unfortunately, this is quite likely going to cause a performance degradation.
This patch therefore restores the behaviour from the 4-0-stable branch by
explicitly forcing the class to define its attribute methods in a similar spot
(when records are initialized). This should not cause any extra roundtrips to
the database because the `@columns` should already be cached on the class.
Fixes #15188.
|