- 30 12月, 2014 2 次提交
-
-
由 Sean Griffin 提交于
Fixes #18237
-
由 Takashi Kokubun 提交于
-
- 29 12月, 2014 1 次提交
-
-
由 Yves Senn 提交于
-
- 28 12月, 2014 4 次提交
-
-
由 Dan Olson 提交于
-
由 Sean Griffin 提交于
We only support classes which provide a no-args constructor to use as a default value. We can provide a more helpful error message if we catch this when `serialize` is called, rather than letting it error when you try to assign the attribute. Fixes #18224
-
由 Ryuta Kamizono 提交于
Example: create_table :foos, id: :bigint do |t| end
-
由 Ryuta Kamizono 提交于
-
- 26 12月, 2014 1 次提交
-
-
由 Ryuta Kamizono 提交于
-
- 23 12月, 2014 5 次提交
-
-
由 Sean Griffin 提交于
Here you go, @senny.
😁 -
由 Yves Senn 提交于
-
由 Yves Senn 提交于
-
由 Daniel Fox 提交于
This bug occurs when an attribute of an ActiveRecord model is an ActiveRecord::Type::Integer type or a ActiveRecord::Type::Decimal type (or any other type that includes the ActiveRecord::Type::Numeric module. When the value of the attribute is negative and is set to the same negative value, it is marked as changed. Take the following example of a Person model with the integer attribute age: class Person < ActiveRecord::Base # age :integer(4) end The following will produce the error: person = Person.new(age: -1) person.age = -1 person.changes => { "age" => [-1, -1] } person.age_changed? => true The problematic line is here: module ActiveRecord module Type module Numeric ... def non_numeric_string?(value) # 'wibble'.to_i will give zero, we want to make sure # that we aren't marking int zero to string zero as # changed. value.to_s !~ /\A\d+\.?\d*\z/ end end end end The regex match doesn't accept numbers with a leading '-'.
-
由 Grey Baker 提交于
-
- 19 12月, 2014 1 次提交
-
-
由 Yves Senn 提交于
-
- 18 12月, 2014 1 次提交
-
-
由 Yves Senn 提交于
Closes #17945 `db:test:prepare` still purges the database to always keep the test database in a consistent state. This patch introduces new problems with `db:schema:load`. Prior to the introduction of foreign-keys, we could run this file against a non-empty database. Since every `create_table` containted the `force: true` option, this would recreate tables when loading the schema. However with foreign-keys in place, `force: true` wont work anymore and the task will crash. /cc @schneems
-
- 11 12月, 2014 1 次提交
-
-
由 Ryuta Kamizono 提交于
-
- 09 12月, 2014 1 次提交
-
-
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.
-
- 05 12月, 2014 2 次提交
-
-
由 Melanie Gilman 提交于
-
由 Melanie Gilman 提交于
Users should pass strings to queries instead of classes
-
- 04 12月, 2014 3 次提交
-
-
由 Yves Senn 提交于
[ci skp]
-
由 Yves Senn 提交于
-
由 noam 提交于
When running the following migration: change_table(:table_name) { |t| t/timestamps } The following error was produced: wrong number of arguments (2 for 1) .... /connection_adapters/abstract/schema_statements.rb:851:in `remove_timestamps' This is due to `arguments` containing an empty hash as its second argument.
-
- 02 12月, 2014 1 次提交
-
-
由 Yves Senn 提交于
-
- 29 11月, 2014 1 次提交
-
-
由 Rafael Mendonça França 提交于
We will support only Ruby >= 2.1. But right now we don't accept pull requests with syntax changes to drop support to Ruby 1.9.
-
- 26 11月, 2014 2 次提交
-
-
由 Jon Atack 提交于
-
由 Yves Senn 提交于
This reverts deprecations added in #13528. The task is brought back for two reasons: 1. Give plugins a way to hook into the test database initialization process 2. Give the user a way to force a test database synchronization While `test:prepare` is still a dependency of every test task, `db:test:prepare` no longer hooks into it. This means that `test:prepare` runs before the schema is synchronized. Plugins, which insert data can now hook into `db:test:prepare`. The automatic schema maintenance can't detect when a migration is rolled-back, modified and reapplied. In this case the user has to fall back to `db:test:prepare` to force the synchronization to happen.
-
- 23 11月, 2014 2 次提交
-
-
由 Arthur Neves 提交于
`.reflections` public API changed to return a String instead of a Symbol as keys. see commit 1f314884 and 6259e4e2 [fixes #16928] [fixes #17610]
-
由 Sean Griffin 提交于
Also checked to make sure this does not affect foreign key constraints. (It doesn't). Fixes #12856 Closes #14088
-
- 21 11月, 2014 2 次提交
-
-
由 siddharth@vinsol.com 提交于
on the joined assoiciation
-
由 Yves Senn 提交于
Prior to this patch you'd end up with an error like: ``` ActiveRecord::RecordNotFound: Couldn't find <Model> with 'id'=<id> [WHERE (<default_scope condition>)] ```
-
- 11 11月, 2014 1 次提交
-
-
由 Cody Cutrer 提交于
-
- 05 11月, 2014 1 次提交
-
-
由 Ted O'Meara 提交于
-
- 03 11月, 2014 2 次提交
-
-
由 Sean Griffin 提交于
This method is still used by `update_all`
-
由 Sean Griffin 提交于
These appear to be implementation relics of times past. They duplicate the logic in Relation, and are no longer used internally.
-
- 02 11月, 2014 1 次提交
-
-
由 Sean Griffin 提交于
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]
-
- 29 10月, 2014 1 次提交
-
-
由 Yves Senn 提交于
The MySQLAdapter type map used the lowest priority for enum types. This was the result of a recent refactoring and lead to some broken lookups for enums with values that match other types. Like `8bit`. This patch restores the priority to what we had before the refactoring. /cc @sgrif
-
- 25 10月, 2014 1 次提交
-
-
由 Derek Prior 提交于
`add_reference` can very helpfully add a multi-column index when you use it to add a polymorphic reference. However, the first column in the index is the `id` column, which is less than ideal. The [PostgreSQL docs][1] say: > A multicolumn B-tree index can be used with query conditions that > involve any subset of the index's columns, but the index is most > efficient when there are constraints on the leading (leftmost) > columns. The [MySQL docs][2] say: > MySQL can use multiple-column indexes for queries that test all the > columns in the index, or queries that test just the first column, the > first two columns, the first three columns, and so on. If you specify > the columns in the right order in the index definition, a single > composite index can speed up several kinds of queries on the same > table. In a polymorphic relationship, the type column is much more likely to be useful as the first column in an index than the id column. That is, I'm more likely to query on type without an id than I am to query on id without a type. [1]: http://www.postgresql.org/docs/9.3/static/indexes-multicolumn.html [2]: http://dev.mysql.com/doc/refman/5.0/en/multiple-column-indexes.html
-
- 20 10月, 2014 2 次提交
-
-
由 Dan Olson 提交于
-
由 Yuki Nishijima 提交于
This would be helpful if 2 models have an attribute that has a similar name to the other. e.g: before: User.new(name: "Yuki Nishijima", projects_attributes: [name: "kaminari"]) # => ActiveRecord::UnknownAttributeError: unknown attribute: name after: User.new(name: "Yuki Nishijima", projects_attributes: [name: "kaminari"]) # => ActiveRecord::UnknownAttributeError: unknown attribute on User: name
-
- 16 10月, 2014 1 次提交
-
-
由 Yuki Nishijima 提交于
This would be helpful if 2 models have an attribute that has a similar name to the other. e.g: before: User.new(name: "Yuki Nishijima", projects_attributes: [name: "kaminari"]) # => ActiveRecord::UnknownAttributeError: unknown attribute: name after: User.new(name: "Yuki Nishijima", projects_attributes: [name: "kaminari"]) # => ActiveRecord::UnknownAttributeError: unknown attribute on User: name
-