- 15 12月, 2015 5 次提交
-
-
由 Matthew Draper 提交于
Apart from specific versioning support, our tests should focus on the behaviour of whatever version they're accompanying, regardless of when they were written. Application code should *not* do this.
-
由 Matthew Draper 提交于
-
由 Sean Griffin 提交于
This reverts commit 6d5b1fdf. `eager_load` and `references` can include hashes, which won't match up with `references` A test case has been added to demonstrate the problem
-
由 Sean Griffin 提交于
There was a test remaining for PG only that was checking for an exact limit clause
-
由 Vokhmin Alexey V 提交于
-
- 14 12月, 2015 2 次提交
-
-
由 Sean Griffin 提交于
We currently generate an unbounded number of prepared statements when `limit` or `offset` are called with a dynamic argument. This changes `LIMIT` and `OFFSET` to use bind params, eliminating the problem. `Type::Value#hash` needed to be implemented, as it turns out we busted the query cache if the type object used wasn't exactly the same object. This drops support for passing an `Arel::Nodes::SqlLiteral` to `limit`. Doing this relied on AR internals, and was never officially supported usage. Fixes #22250.
-
由 Sean Griffin 提交于
Some backends allow `LIMIT 1,2` as a shorthand for `LIMIT 1 OFFSET 2`. Supporting this in Active Record massively complicates using bind parameters for limit and offset, and it's trivially easy to build an invalid SQL query by also calling `offset` on the same `Relation`. This is a niche syntax that is only supported by a few adapters, and can be trivially worked around by calling offset explicitly.
-
- 13 12月, 2015 1 次提交
-
-
由 Fumiaki MATSUSHIMA 提交于
-
- 07 12月, 2015 2 次提交
-
-
由 Arthur Neves 提交于
The problem was that when saving an object, we would call touch_later on the parent which wont be saved immediteally, and it wont call any callbacks. That was working one level up because we were calling touch, during the touch_later commit phase. However that still didnt solve the problem when you have a 3+ levels of parents to be touched, as calling touch would affect the parent, but it would be too late to run callbacks on its grand-parent. The solution for this, is instead, call touch_later upwards when the first touch_later is called. So we make sure all the timestamps are updated without relying on callbacks. This also removed the hard dependency BelongsTo builder had with the TouchLater module. So we can still have the old behaviour if TouchLater module is not included. [fixes 5f5e6d92] [related #19324]
-
由 Genadi Samokovarov 提交于
Those are actually shortcuts for `after_commit`. Before: after_commit :add_to_index_later, on: :create after_commit :update_in_index_later, on: :update after_commit :remove_from_index_later, on: :destroy After: after_create_commit :add_to_index_later after_update_commit :update_in_index_later after_destroy_commit :remove_from_index_later
-
- 05 12月, 2015 1 次提交
-
-
由 yuuji.yaginuma 提交于
This removes the following warning which has been out in the case of a PostgreSQL 9.3 below. ``` activerecord/test/cases/adapters/postgresql/geometric_test.rb:265: warning: instance variable @connection not initialized ```
-
- 03 12月, 2015 1 次提交
-
-
由 Yves Senn 提交于
This will also get the defaults from attribute definitions like: attribute :type, :string, default: "SomethingElse"
-
- 02 12月, 2015 4 次提交
-
-
由 Yves Senn 提交于
`has_attribute?` method to check wether a given attribute has been defined.
-
由 Yves Senn 提交于
This solves the following error: ActiveRecord::StatementInvalid: Could not find table 'guitars' It seems that the table structure of the `Guitar` model has not been necessary until now. Due to the wrong table name the model was not correctly linked to the table.
-
由 Kuldeep Aggarwal 提交于
fixes #17121
-
由 Sean Griffin 提交于
It appears that I missed this one when I delegated all the non-mutation array methods that were not on Enumerable
-
- 01 12月, 2015 2 次提交
-
-
由 Yasuo Honda 提交于
-
由 Yasuo Honda 提交于
-
- 24 11月, 2015 4 次提交
-
-
由 Sean Griffin 提交于
-
由 Ryuta Kamizono 提交于
-
由 Ryuta Kamizono 提交于
-
由 Sean Griffin 提交于
As was pointed out by #17128, our blacklist of mutation methods was non-exhaustive (and would need to be kept up to date with each new version of Ruby). Now that `Relation` includes `Enumerable`, the number of methods that we actually need to delegate are pretty small. As such, we can change to explicitly delegating the few non-mutation related methods that `Array` has which aren't on `Enumerable`
-
- 23 11月, 2015 1 次提交
-
-
由 Bogdan Gusiev 提交于
When same association is loaded in the model creation callback The new object is inserted into association twice
-
- 21 11月, 2015 1 次提交
-
-
由 yui-knk 提交于
`replace_named_bind_variables` and `replace_bind_variables` are definded in `sanitization.rb`, so it is reasonable these tests are on `sanitize_test.rb`.
-
- 20 11月, 2015 4 次提交
-
-
由 Ryuta Kamizono 提交于
Follow up to #21601.
-
由 Nick Muerdter 提交于
If postgresql is being used and there are multiple schemas listed on the `schema_search_path`, then `structure.sql` dumps (triggered by `rake db:structure:dump` or `config.active_record.schema_format = :sql`) began failing in Rails 4.2.5. This is due to the changes made in https://github.com/rails/rails/pull/17885 The problem is that multiple schemas were getting getting passed to `Kernel.system` as a single, space delimited string argument (for example, "--schema=foo --schema=bar"). However, with the updated array style of calling `Kernel.system`, these need to be passed as separate arguments (for example, "--schema=foo", "--schema=bar"). If they get passed as a single string, then the underlying pg_dump program isn't sure how to interpret that single argument and you'll get an error reporting: "pg_dump: No matching schemas were found"
-
由 Sean Griffin 提交于
This reverts commit 8246b593. There was concern about this modifying the behavior of past migrations. We're going to add an way to modify the migration generator instead.
-
由 Sean Griffin 提交于
It's often the case that you want to have an option that you cannot specify at the database level, but want applied to *all* tables that you create. For example, you might want to specify `ROW_FORMAT=DYNAMIC` to not have to limit text columns to length 171 for indexing when using utf8mb4. This allows an easy way to specify this in your database configuration. While this change affects both MySQL and MySQL2, the test only covers MySQL2, as the legacy mysql adapter appears to always return ASCII strings, and is tangential to what we're actually doing.
-
- 18 11月, 2015 1 次提交
-
-
由 Sam Davies 提交于
- key was a poor choice of name. A key implies something that will unlock a lock. The concept is actually more like a 'lock identifier' - mysql documentation calls this a 'lock name' - postgres documentation calls it a 'lock_id' - Updated variable names to reflect the preferred terminology for the database in question
-
- 17 11月, 2015 1 次提交
-
-
由 Andrew White 提交于
In b71e08f8 we started raising when nil or false was passed to merge to fix #12264, however we should also do this for truthy values that are invalid like true.
-
- 16 11月, 2015 1 次提交
-
-
由 yui-knk 提交于
If argument of `build_record` has key and value which is same as default value of database, we should also except the key from `create_scope` in `initialize_attributes`. Because at first `build_record` initialize record object with argument of `build_record`, then assign attributes derived from Association's scope. In this case `record.changed` does not include the key, which value is same as default value of database, so we should add the key to except list. Fix #21893.
-
- 14 11月, 2015 1 次提交
-
-
由 Tim Breitkreutz 提交于
-
- 12 11月, 2015 1 次提交
-
-
由 yui-knk 提交于
From Ruby ( 2.3.0dev trunk 52520), `Hash#to_proc` is defined (https://github.com/ruby/ruby/commit/fbe967ec02cb65a7efa3fb8f3d747cf6f620dde1), and many tests have been failed with `ArgumentError: wrong number of arguments (given 0, expected 1)`. Because we call `Hash#to_proc` with no args in `#merge!`. This commit changes order of conditionals to not call `Hash#to_proc`.
-
- 09 11月, 2015 2 次提交
-
-
由 yui-knk 提交于
Reported on #21509, how views is treated by `#tables` are differ by each adapters. To fix this different behavior, after Rails 5.0 is released, deprecate `#tables`. And `#table_exists?` would check both tables and views. To make their behavior consistent with `#tables`, after Rails 5.0 is released, deprecate `#table_exists?`.
-
由 yui-knk 提交于
And add code examples to `sanitize_sql_for_conditions`, `sanitize_sql_for_assignment`, and `sanitize_sql_array`.
-
- 08 11月, 2015 1 次提交
-
-
由 Kassio Borges 提交于
Skipping `marked_for_destruction?` when the associated object does not responds to it make easier to validate virtual associations built on top of Active Model objects and/or serialized objects that implement a `valid?` instance method.
-
- 07 11月, 2015 4 次提交
-
-
由 Sean Griffin 提交于
The previous commit changes the state of the class, and while we are cleaning up the database, I forgot to clean up the class
-
由 Sean Griffin 提交于
I've added a redundant test for this under the attributes API as well, as that also causes this bug to manifest through public API (and demonstrates that calling `reset_column_information` on the child classes would be insufficient) Since children of a class should always share a table with their parent, just reloading the schema from the cache should be sufficient here. `reload_schema_from_cache` should probably become public and `# :nodoc:`, but I'd rather avoid the git churn here. Fixes #22057
-
由 Kasper Timm Hansen 提交于
It goes expected, then actual. Only changed this because the file was just touched (please don't submit pull requests :)).
-
由 yui-knk 提交于
These warings have been appeared from https://github.com/rails/rails/commit/92bc8cdb0771bf6ffcfb31ef58dba529527b514c
-