| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|\
| |
| |
| |
| | |
kamipo/test_binary_data_is_not_logged_is_for_prepared_statements
`test_binary_data_is_not_logged` is for prepared statements logging
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|/
|
|
|
|
| |
Columns are no longer stored in an attribute since b8a533d.
[ci skip]
|
| |
|
|\
| |
| |
| |
| | |
yuki24/deprecate-original-exception-infavor-of-cause
Deprecate exception#original_exception in favor of exception#cause
|
| | |
|
|/
|
|
|
|
| |
This test case was definded by 51de8cee82d61541725ff4c2462b083f37e64017.
`float` and `double` is registered in abstract_mysql_adapter.rb,
we should test not only for mysql adapter, but mysql2 adapter.
|
|\
| |
| | |
Make `db:migrate:status` to render `1_some.rb` format migrate files.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
`1_valid_people_have_last_names.rb` and
`20150823202140_create_users.rb` are valid migration file name.
But `1_valid_people_have_last_names.rb` is rendered as
`********** NO FILE **********` when `rake db:migrate:status`.
Fix to this bug, this commit includes
* define some API private methdos and a Constant
`match_to_migration_filename?`, `parse_migration_filename`, and
`MigrationFilenameRegexp`
* use these methods in `db:migrate:status` task
Example:
These files are in `db/migrate`
* 1_valid_people_have_last_names.rb
* 20150819202140_irreversible_migration.rb
* 20150823202140_add_admin_flag_to_users.rb
* 20150823202141_migration_tests.rb
* 2_we_need_reminders.rb
* 3_innocent_jointable.rb
we can migrate all of them.
Before
```shell
$ bundle exec rake db:migrate:status
...
Status Migration ID Migration Name
--------------------------------------------------
up 001 ********** NO FILE **********
up 002 ********** NO FILE **********
up 003 ********** NO FILE **********
up 20150819202140 Irreversible migration
up 20150823202140 Add admin flag to users
up 20150823202141 Migration tests
```
After
```shell
$ bundle exec rake db:migrate:status
...
Status Migration ID Migration Name
--------------------------------------------------
up 001 Valid people have last names
up 002 We need reminders
up 003 Innocent jointable
up 20150819202140 Irreversible migration
up 20150823202140 Add admin flag to users
up 20150823202141 Migration tests
```
|
|/
|
|
|
|
| |
`DEFAULT_CHARSET` and `DEFAULT_COLLATION` in `MySQLDatabaseTasks`
was changed by 322068fe85278ea26e26da6dfd7c5612dab15a72.
This test case also should be changed.
|
|
|
|
| |
This commit follows up of 6a6dbb4c51fb0c58ba1a810eaa552774167b758a.
|
|
|
|
| |
Such as #10404, #18206.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit f6ca7e4e75408bc42f515fc7206d6c6ff0dce7c6.
The default collation of utf8 in MySQL is the `utf8_general_ci`, and
this should not be changed. This is because, the better collation in the
all locales is not exists, optimal collation in own application is not
known other than themselves.
The `utf8_unicode_ci` is known as Japanese killer in Japan, there are
serious impacts in search of Japanese.
MySQL implements the `utf8_unicode_ci` according to the Unicode
Collation Algorithm (UCA) described at http://www.unicode.org/reports/tr10/,
but the `utf8_unicode_ci` have only partial support for the UCA, only
primary level key comparison implemented (also known as L1 (Base
characters) comparison).
Because L1 (Base characters) comparison does not distinguish between the
presence or absence of the accent, if distinction of the accent is
important there is a serious impact (e.g. Japanese).
Example:
```
> SHOW CREATE TABLE `dicts`\G
*************************** 1. row ***************************
Table: dicts
Create Table: CREATE TABLE `dicts` (
`word` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
`meaning` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci
1 row in set (0.00 sec)
> INSERT INTO `dicts` VALUES ('ハハ', 'mother'), ('パパ', 'father');
Query OK, 2 rows affected (0.00 sec)
> SELECT * FROM `dicts` WHERE `word` = 'ハハ';
+--------+---------+
| word | meaning |
+--------+---------+
| ハハ | mother |
| パパ | father |
+--------+---------+
2 rows in set (0.00 sec)
> CREATE UNIQUE INDEX `unique_index_word` ON `dicts`(`word`);
ERROR 1062 (23000): Duplicate entry 'ハハ' for key 'unique_index_word'
```
We should omit the collation entirely rather than providing a default.
Then the choice is the responsibility of the server and MySQL distribution.
|
| |
|
|\
| |
| | |
Move some AR test cases to inheritance_test.rb
|
| |
| |
| |
| |
| |
| |
| |
| | |
These methods are defined in inheritance.rb
* `abstract_class?`
* `descends_from_active_record?`
* `compute_type`
|
| | |
|
| |
| |
| |
| |
| | |
* add newline for display the fenced code block
* add "#" in the comments section
|
|\ \
| | |
| | | |
Alias left_joins to left_outer_joins
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
we should be using a countdown latch instead of rolling our own
busy-loop.
|
|\ \ \
| | | |
| | | |
| | | |
| | | | |
samphilipd/sam/manual_locking_on_schema_migrations
Make migrations concurrent safe (using advisory locks)
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
- Addresses issue #22092
- Works on Postgres and MySQL
- Uses advisory locks because of two important properties:
1. The can be obtained outside of the context of a transaction
2. They are automatically released when the session ends, so if a
migration process crashed for whatever reason the lock is not left
open perpetually
- Adds get_advisory_lock and release_advisory_lock methods to database
adapters
- Attempting to run a migration while another one is in process will
raise a ConcurrentMigrationError instead of attempting to run in
parallel with undefined behavior. This could be rescued and
the migration could exit cleanly instead. Perhaps as a configuration
option?
Technical Notes
==============
The Migrator uses generate_migrator_advisory_lock_key to build the key
for the lock. In order to be compatible across multiple adapters there
are some constraints on this key.
- Postgres limits us to 64 bit signed integers
- MySQL advisory locks are server-wide so we have to scope to the
database
- To fulfil these requirements we use a Migrator salt (a randomly
chosen signed integer with max length of 31 bits) that identifies
the Rails migration process as the owner of the lock. We multiply
this salt with a CRC32 unsigned integer hash of the database name to
get a signed 64 bit integer that can also be converted to a string
to act as a lock key in MySQL databases.
- It is important for subsequent versions of the Migrator to use the
same salt, otherwise different versions of the Migrator will not see
each other's locks.
|
| |/ /
|/| |
| | |
| | |
| | |
| | | |
This assumes only one query was ever executed, but it appears to
sometimes be loading schema information. We can just look at the array
of queries, rather than the "first" one that was run
|
|\ \ \
| |_|/
|/| |
| | | |
added ActiveRecord::Relation#outer_joins
|
| | |
| | |
| | |
| | |
| | |
| | | |
Example:
User.left_outer_joins(:posts)
=> SELECT "users".* FROM "users" LEFT OUTER JOIN "posts" ON "posts"."user_id" = "users"."id"
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Before this commit, if
`ActiveRecord::Base.belongs_to_required_by_default` is set to `true`,
then creating a record through `has_and_belongs_to_many` fails with the
cryptic error message `Left side must exist`. This is because
`inverse_of` isn't working properly in this case, presumably since we're
doing trickery with anonymous classes in the middle.
Rather than following this rabbit hole to try and get `inverse_of` to
work in a case that we know is not publicly supported, we can just turn
off this validation to match the behavior of 4.2 and earlier.
|
| | | |
|
|\ \ \
| | | |
| | | |
| | | | |
Support SQL sanitization in AR::QueryMethods#order
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Add support for sanitizing arrays in SQL ORDER clauses.
This is useful when using MySQL `ORDER BY FIELD()` to return records in
a predetermined way.
```ruby
Tag.order(['field(id, ?', [1,3,2]].to_sql
# => SELECT "tags".* FROM "tags" ORDER BY field(id, 1,3,2)
```
Prior to this, developers must be careful to sanitize `#order` arguments
themselves.
|
|\ \ \ \
| | | | |
| | | | | |
PostgreSQL, Replace static connection param list by libpq's dynamic list
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This makes the connection adapter future-proof regarding to new parameters.
To maintain backward compatibility, :requiressl is added by hand. It is
deprecated by PostgreSQL since 2003, but still accepted by libpq.
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This is part of a refactoring to make it easier to allow `order` to use
sanitize like just about everything else on relation. The deleted test
doesn't give any reasoning as to why passing `nil` to `order` needs to
be supported, and it's rather nonsensical. I can almost see allowing an
empty string being passed (though I'm tempted to just disallow it...)
|
|\ \ \ \ \
| | | | | |
| | | | | | |
default value for FixtureSet.fixture_class_names ought to be a Class
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Look at `TestFixtures.set_fixture_class`. As documented, it
accepts a mapping of fixture identifiers (string or symbol) to Classes
(the model classes that implement the named fixture).
Look now at the initialization of `TestFixtures.fixture_class_names`.
It defines a Hash, which will return a string by default (where the
string is the estimated class name of the given fixture identifier).
Now look at TestFixtures.load_fixtures. It calls `FixtureSet.create_fixtures`,
passing in the mapping of `fixture_class_names`.
Following this on to `FixtureSet.create_fixtures`, this instantiates a
`FixtureSet::ClassCache`, passing in the map of class names.
`ClassCache`, in turn, calls `insert_class` for each value in the cache.
(Recall that `set_fixture_class` puts Class objects in there, while the
default proc for the mapping puts String objects.)
Look finally at `insert_class`. If the value is present, it checks to
see if the value is a subclass of `AR::Base`. Fair enough...but wait!
What if the value is a String? You get an exception, because a String
instance cannot be compared with a Class.
Judging from the implementation, it seems like the expected behavior
here is for `fixture_class_names` to have no default proc. Look-ups are
supposed to happen via `ClassCache`, with `fixture_class_names` existing
solely as a repository for explicitly-registered class mappings.
That is what this change does.
|
| | | | | | |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
akihiro17/fix-preload-association""
This reverts commit 5243946017d09afff4d70d273b0fcdfd41a4b22a.
This fixes an issue with the build where tests would fail on mysql and
postgresql due to different ordering.
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | | |
Avoid disabling postgres errors
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
In Postgres 8.1 the standard_conforming_strings setting was read-only,
meaning you got an error if you tried to update it. By filtering on
`context = 'user'` we only try to update the setting if it's
user-writable[1].
[1]: http://www.postgresql.org/docs/9.4/static/view-pg-settings.html
|
| |/ / / / /
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The standard_conforming_strings setting doesn't exist on all versions of
Postgres, but if it does exist, Rails turns it on. Previously this was done by
effectively disabling errors on the Postgres connection, issuing a SET to turn
the setting on, then re-enabling errors on the connection. However, if you're
running pgbouncer in transaction-pooling mode, you can't guarantee that
successive calls to `#execute` will be sent to the same pgbouncer-postgres
connection, so you can end up disabling errors on a different postgres
connection, and never re-enabling them. Future queries on that connection that
result in errors (e.g. violating unique constraints) will leave the connection
in a bad state where successive queries will fail.
This commit sets standard_conforming_strings by issuing an UPDATE to
pg_settings, which will update the setting if it exists, and do nothing if it
doesn't (rather than erroring out like SET would), which means we can remove
the error-disabling code.
It's also worth noting that Postgres has allowed standard_conforming_strings to
be updated since 8.2 (which is the oldest version Rails supports), so
technically we probably don't even need to be defensive here.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This reverts commit 6dc6a0b17cfaf7cb6aa2b1c163b6ca141b538a8e, reversing
changes made to ec94f00ba3cf250eb54fc5b7a5e3ed4b90164f34.
This pull request broke the build.
|
|\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | | |
DRY up STI subclass logic
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
We don't need to use `String#+` or create all the intermediate strings
to break a string into multiple lines. We can just write a c-style
multiline string literal. This is by no means a hotpath, but this is
clearer to me anyway.
|
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
The first one is quite straightforward. We want to give the proper error
message in the case where a top level constant exists, but we're looking
for a nested one. We just need to port over the change to use
`subclass.name` into these changes.
The second set of failures, which are only present in the mysql adapter
tests, are stranger to me. The failure occurs because we were
previously comparing `subclass.name == self.name` instead of `subclass
== self`. However, I don't think that we need to support creating
anonymous classes which share a table with a class that uses STI,
overrides `name` to return the same name as athe class that we have no
other relationship with, when not assigned to a constant so it could
never be used anyway...
The commits around why that exist give no context, and I think they're
just poorly written tests (WTF does `test_schema` mean anyway, and why
does calling `.first` on some anonymous class test it?). We'll just
disable STI on that class.
|