| Commit message (Collapse) | Author | Age | Files | Lines |
|\ |
|
| |
| |
| |
| | |
Follow up of https://github.com/rails/rails/commit/c9feea6c9ab4494b0cb0b8cf4316847854f65af6
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This reverts commit 99801c6a7b69eb4b006a55de17ada78f3a0fa4c1.
Ultimately it doesn't matter whether `add_index` or `t.index` are used
in the schema dumper in any meaningful way. There are gems out there
which hook into the old behavior for things like indexing materialized
views. Since the reverted commit doesn't seem to add much benefit,
there's no reason for us to break these gems.
|
| | |
|
| | |
|
| | |
|
|\ \
| | |
| | | |
Active Record supports MySQL >= 5.0
|
| | |
| | |
| | |
| | |
| | | |
Currently some features uses `information_schema` (e.g. foreign key
support). `information_schema` introduced since MySQL 5.0.
|
|\ \ \
| |/ /
|/| | |
Defer Arel attribute lookup to the model class
|
| | |
| | |
| | |
| | |
| | | |
This still isn't as separated as I'd like, but it at least moves most of
the burden of alias mapping in one place.
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | |
| | | | |
Changed id-writer to save join table records based on association
primary key #20995.
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
key #20995
Changed id-writer to save join table records based on association primary key
|
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We had previously updated this to attempt to map over whatever was
passed in, so that additional types like range and array could benefit
from this behavior without the time zone converter having to deal with
every known type.
However, the default behavior of a type is to just yield the given value
to `map`, which means that if we don't actually know how to handle a
value, we'll just recurse infinitely. Since both uses of `map` in this
case occur in cases where we know receiving the same object will
recurse, we can just break on reference equality.
Fixes #23241.
|
|\ \ \
| | | |
| | | | |
Warn if a named scope is overwriting an existing scope or method
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This reverts commit f6db31ec16e42ee7713029f7120f0b011d1ddc6c.
Reason:
Scope names can very easily conflict, particularly when sharing Concerns
within the team, or using multiple gems that extend AR models.
It is true that Ruby has the ability to detect this with the -w option, but the
reality is that we are depending on too many gems that do not care about Ruby
warnings, therefore it might not be a realistic solution to turn this switch on
in our real-world apps.
|
|\ \ \ \
| | | | |
| | | | | |
Fix corrupt transaction state caused by `before_commit` exceptions
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
When a `before_commit` callback raises, the database is rolled back but
AR's record of the current transaction is not, leaving the connection in
a perpetually broken state that affects all future users of the
connection: subsequent requests, jobs, etc. They'll think a transaction
is active when none is, so they won't BEGIN on their own. This manifests
as missing `after_commit` callbacks and broken ROLLBACKs.
This happens because `before_commit` callbacks fire before the current
transaction is popped from the stack, but the exception-handling path
they hit assumes that the current transaction was already popped. So the
database ROLLBACK is issued, but the transaction stack is left intact.
Common cause: deadlocked `#touch`, which is now implemented with
`before_commit` callbacks.
What's next:
* We shouldn't allow active transaction state when checking in or out
from the connection pool. Verify that conns are clean.
* Closer review of txn manager sad paths. Are we missing other spots
where we'd end up with incorrect txn state? What's the worst that can
happen if txn state drifts? How can we guarantee it doesn't and
contain the fallout if it does?
Thanks for @tomafro for expert diagnosis!
|
|/ / / /
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This reverts commit 9f3730a516f30beb0050caea9539f8d6b808e58a, reversing
changes made to 2637fb75d82e1c69333855abd58c2470994995d3.
There are additional issues with this commit that need to be addressed
before this change is ready (see #23377). This is a temporary revert in
order for us to have more time to address the issues with that PR,
without blocking the release of beta2.
|
| | | |
| | | |
| | | |
| | | | |
for those who already migrated to Rails 5.0.0 beta
|
| | | |
| | | |
| | | |
| | | | |
to support Oracle database which only supports 30 byte identifier length
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
`initialize_schema_migrations_table` is called in every migrations.
https://github.com/rails/rails/blob/v5.0.0.beta1/activerecord/lib/active_record/migration.rb#L1080
https://github.com/rails/rails/blob/v5.0.0.beta1/activerecord/lib/active_record/schema.rb#L51
This means that extra `show variables` is called regardless of the
existence of `schema_migrations` table.
This change is to avoid extra `show variables` if `schema_migrations`
table exists.
|
|\ \ \ \
| | | | |
| | | | | |
Make to primary key instead of an unique index for internal tables
|
| | | | | |
|
| | | | | |
|
|\ \ \ \ \
| | | | | |
| | | | | | |
Added test for backward compatibility of null constraints on timestamp columns
|
| |/ / / / |
|
|/ / / / |
|
|\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
yui-knk/warning_when_composite_primary_key_is_detected
Warn if `AR.primary_key` is called for a table who has composite prim…
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
If `AR.primary_key` is called for a table who has composite primary key,
the method returns `nil`. This behavior sometimes generates invalid SQL.
The first time developers notice to invalid SQL is when they execute
SQL. This commit enables developers to know they are doing something
dangerous as soon as possible.
|
|\ \ \ \ \
| | | | | |
| | | | | | |
Fix `bigint?` for Enum columns in MySQL
|
| |/ / / /
| | | | |
| | | | |
| | | | | |
Follow up to #22896.
|
|/ / / / |
|
|/ / /
| | |
| | |
| | | |
instead of loading relation
|
|\ \ \
| | | |
| | | | |
Raise AR::IrreversibleOrderError when #reverse_order can not do it's job
|
| | | |
| | | |
| | | |
| | | |
| | | | |
Raises when #reverse_order can not process SQL order instead of making
invalid SQL before this patch
|
|/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The commit which originally added this behavior did not consider that
doing `Subclass.new` does not actually populate the `type` field in the
attributes (though perhaps it should). We simply need to not use the
defaults for STI related things unless we are instantiating the base
class.
Fixes #23285.
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
* 5-0-beta-sec:
bumping version
fix version update task to deal with .beta1.1
Eliminate instance level writers for class accessors
allow :file to be outside rails root, but anything else must be inside the rails view directory
Don't short-circuit reject_if proc
stop caching mime types globally
use secure string comparisons for basic auth username / password
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
When updating an associated record via nested attribute hashes the
reject_if proc could be bypassed if the _destroy flag was set in the
attribute hash and allow_destroy was set to false.
The fix is to only short-circuit if the _destroy flag is set and the
option allow_destroy is set to true. It also fixes an issue where
a new record wasn't created if _destroy was set and the option
allow_destroy was set to false.
CVE-2015-7577
|
|\ \ \ \
| | | | |
| | | | | |
[close #23009] Limit key length
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Mysql has a weird bug where it cannot index a string column of utf8mb4 if it is over a certain character limit. To get compatibility with msql we can add a limit to the key column. 191 characters is a very long key, it seems reasonable to limit across all adapters since using a longer key wouldn't be supported in mysql.
Thanks to @kamipo for the original PR and the test refactoring.
Conversation: https://github.com/rails/rails/pull/23009#issuecomment-171416629
|
| | | | | |
|
|\ \ \ \ \
| | | | | |
| | | | | | |
Add missing source_type if provided on hmt which belongs to an sti re…
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Fixes #23209
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
- We don't need the select scope added by user as we only want to max
timestamp and size of the collection. So we already know which columns
to select.
- Additionally having user defined columns in select scope blows the cache_key
method with PostGreSQL because it needs all `selected` columns in the group_by
clause or aggregate function.
- Fixes #23038.
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
prathamesh-sonpatki/fix-cache-key-for-queries-with-offset
Fix ActiveRecord::Relation#cache_key for relations with no results
|
| | |_|_|_|/
| |/| | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
- When relations return no result or 0 result then cache_key should
handle it gracefully instead of blowing up trying to access
`result[:size]` and `result[:timestamp]`.
- Fixes #23063.
|