| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Ruby-pg's default way to serialize values for transmission to the database is to
call #to_s . This however creates a temporary String object for each value.
Setting a class based type map avoids the allocation of this additional String.
The performance benefit is measurable in microbenchmarks, but not with
the overhead of activerecord. However it's free to use and has no drawback.
|
|\| | |
| | | |
| | | |
| | | |
| | | | |
Merges 1d8d5a74b81b8aab1f5e6d233d509a92525ed4e1. The pull request as a
whole is quite large, and I'm reviewing the smaller pieces individually.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The type map was introduced in aafee23, but wasn't properly filled.
This mainly adjusts many locations, that expected strings instead of
integers or boolean.
add_pg_decoders is moved after setup of the StatementPool, because
execute_and_clear could potentially make use of it.
|
|\ \ \ \
| | | | |
| | | | | |
Add `config.active_record.warn_on_result_set_size` option
|
| |/ / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
When set to an integer, a warning will be logged whenever a result set
larger than the specified size is returned by a query. Fixes #16463
The warning is outputed a module which is prepended in an initializer,
so there will be no performance impact if
`config.active_record.warn_on_records_fetched_greater_than` is not set.
|
|\ \ \ \
| |/ / /
|/| | |
| | | |
| | | | |
Conflicts:
guides/source/4_0_release_notes.md
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | |
| | | | | |
Avoid loading user's psqlrc when loading test structure
|
|/ / / / |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This reverts commit 5cfa6a8ab997089c3012a82052c8c317b2e095f5, reversing
changes made to bfd5bf8313e6ea0bb2eccb68ee5076bb63f0b2db.
Reason: This broken travis build.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
the newer method used for discriminating new records did not
use the older and more robust method used for instantiating
existing records, but did have a better post-check to ensure
the sublass was in the hierarchy. so move the descendants check
to find_sti_class, and then simply call find_sti_class from
subclass_from_attributes
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
pinglamb/fix-referencing-wrong-alias-when-joining-tables-of-has-many-through-association
Fix referencing wrong aliases while joining tables of has many through association
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
association
While joining table of has_many :through association, ActiveRecord will
use the actual table name instead of through-join alias. It results with
a wrong SQL and exception is raised. This only happens when calculation
methods like #count is called.
This issue is affecting Rails 4.1.x and 4.2.x as well.
|
|\ \ \ \ \
| | | | | |
| | | | | | |
PostgreSQL, Add test case for "Infinity" string assignment to float columns
|
| |/ / / /
| | | | |
| | | | |
| | | | | |
This is implemented in Type::Float, but not tested, so far.
|
| | | | | |
|
|\ \ \ \ \
| | | | | |
| | | | | | |
remove old unavailable link with relevant fix patch 1
|
| | | | | | |
|
|/ / / / / |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This is obviously all very internal, but sometimes you have to look at
it... and when you do, it'll save a lot of confusion if it doesn't lie
about its identity.
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
The subtype will (quite reasonably) ignore the possibility that it has
`changed_in_place?` by becoming nil.
Fixes #19467
|
|/ / / / |
|
|\ \ \ \
| |_|/ /
|/| | | |
Fix documentation for find_or_create_by
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
The code in the comment fails on concurrent inserts if done inside a transaction.
The fix is to force a savepoint to run so that if the database raises an unique violation exception. Otherwise, you'll get errors like:
```
(0.3ms) BEGIN
Cart Load (0.5ms) SELECT "carts".* FROM "carts" WHERE "carts"."uuid" = '12345' LIMIT 1
# Another process inserts a cart with uuid of '12345' right now
SQL (4371.7ms) INSERT INTO "carts" ("created_at", "updated_at", "uuid") VALUES ('2015-03-21 01:05:07.833231', '2015-03-21 01:05:07.833231', '12345') RETURNING "id" [["created_at", Sat, 21 Mar 2015 01:05:07 PDT -07:00], ["updated_at", Sat, 21 Mar 2015 01:05:07 PDT -07:00], ["uuid", "12345"]]
PG::UniqueViolation: ERROR: duplicate key value violates unique constraint "carts_uuid_idx1"
DETAIL: Key (uuid)=(12345) already exists.
: INSERT INTO "carts" ("created_at", "updated_at", "uuid") VALUES ('2015-03-21 01:05:07.833231', '2015-03-21 01:05:07.833231', '12345') RETURNING "id"
# Retrying the find
Cart Load (0.8ms) SELECT "carts".* FROM "carts" WHERE "carts"."uuid" = '12345' LIMIT 1
PG::InFailedSqlTransaction: ERROR: current transaction is aborted, commands ignored until end of transaction block
: SELECT "carts".* FROM "carts" WHERE "carts"."uuid" = '12345' LIMIT 1
(0.1ms) ROLLBACK
ActiveRecord::StatementInvalid: PG::InFailedSqlTransaction: ERROR: current transaction is aborted, commands ignored until end of transaction block
: SELECT "carts".* FROM "carts" WHERE "carts"."uuid" = '12345' LIMIT 1
```
|
|/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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
|
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Preserving RACK_ENV behavior.
This reverts commit 7bdc7635b885e473f6a577264fd8efad1c02174f, reversing
changes made to 45786be516e13d55a1fca9a4abaddd5781209103.
|
| | |
| | |
| | |
| | | |
Fixes #19389.
|
| | |
| | |
| | |
| | | |
skip]
|
| | | |
|
|\ \ \
| | | |
| | | | |
Updated MySQL documentation link for STRICT_ALL_TABLES [ci skip]
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | | |
Don't fallback to RACK_ENV when RAILS_ENV is not present
|
| | | | | |
|
| |/ / /
|/| | |
| | | |
| | | |
| | | |
| | | | |
ActiveRecord: Add a changelog entry for issue #17680. [ci skip]
Conflicts:
activerecord/CHANGELOG.md
|
|/ / / |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is a better test for 51660f0. It is testing that the SQL is the
same before and after the previously leaky scope is called. Before if
`hotel.drink_designers` was called first then `hotel.recipes` would
incorrectly get the scope applied. We want to be sure that the
polymorphic hm:t association is not leaking into or affecting the
SQL for the hm:t association on `Hotel`.
The reason I couldn't do this before was because there was an issue with
the SQL getting cached and wanted to resolve that later and then fix the
test to be better. Because of the caching, this test requires that
`Hotel.reflect_on_association(:recipes).clear_association_scope_cache`
be called after the first call to `hotel.recipes` to clear the
assocation scope chain and not interfere with the rest of the test.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In the tests if I were to call `post.categorizations.to_a` and then later call
`post.categorizations.to_a` expecting to have different results the 2 queries
would be the same because of the caching involved in
`@association_scope_cache`. The chain gets cached and the queries will
be the same even if they are not supposed to be (i.e. testing an order
dependent scoping issue).
I found this issue because I was working on a bug with cached scoped
in hm:t and hm:t polymorphic relationships but `capture_sql` was
outputting the wrong SQL to write a good test.
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Reuse the CollectionAssociation#reader proxy cache if the foreign key is present from the start.
Conflicts:
activerecord/CHANGELOG.md
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
present from the start.
When a new record has the necessary information prior to save, we can
avoid busting the cache.
We could simply clear the @proxy on #reset or #reset_scope, but that
would clear the cache more often than necessary.
|
| | | |
| | | |
| | | | |
Update link in comments to point to latest MySQL production version documentation. See here for reference: http://dev.mysql.com/doc/refman/5.0/en/choosing-version.html
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Fixes db:structure:dump when using schema_search_path and PostgreSQL
extensions.
Closes #17157.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
It is redundant with tests in `eager_loading?`, but for the difference
between `includes_values.present?` and `includes_values.any?`, which
is a difference without a distinction because `false` has no meaning
for `includes`.
|
| | | | |
|
| | | | |
|
|\ \ \ \
| | | | |
| | | | | |
Materialize subqueries by adding `DISTINCT` to suport MySQL 5.7.6 and later
|
| |/ / /
| | | |
| | | |
| | | | |
to support MySQL 5.7.6 `optimizer_switch='derived_merge=on'`
|
|/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
I’m renaming all instances of `use_transcational_fixtures` to
`use_transactional_tests` and “transactional fixtures” to
“transactional tests”.
I’m deprecating `use_transactional_fixtures=`. So anyone who is
explicitly setting this will get a warning telling them to use
`use_transactional_tests=` instead.
I’m maintaining backwards compatibility—both forms will work.
`use_transactional_tests` will check to see if
`use_transactional_fixtures` is set and use that, otherwise it will use
itself. But because `use_transactional_tests` is a class attribute
(created with `class_attribute`) this requires a little bit of hoop
jumping. The writer method that `class_attribute` generates defines a
new reader method that return the value being set. Which means we can’t
set the default of `true` using `use_transactional_tests=` as was done
previously because that won’t take into account anyone using
`use_transactional_fixtures`. Instead I defined the reader method
manually and it checks `use_transactional_fixtures`. If it was set then
it should be used, otherwise it should return the default, which is
`true`. If someone uses `use_transactional_tests=` then it will
overwrite the backwards-compatible method with whatever they set.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | | |
|