- 12 6月, 2015 3 次提交
-
-
由 Aster Ryan 提交于
-
由 Sean Griffin 提交于
[Sean Griffin & jmondo]
-
由 Sean Griffin 提交于
If the subtype provides custom schema dumping behavior, we need to defer to it. We purposely choose not to handle any values other than an array (which technically should only ever be `nil`, but I'd rather code defensively here). Fixes #20515.
-
- 05 6月, 2015 1 次提交
-
-
由 Sean Griffin 提交于
This introduces a deprecation cycle to change the behavior of the default point type in the PostgreSQL adapter. The old behavior will continue to be available for the immediate future as `:legacy_point`. The current behavior of returning an `Array` causes several problems, the most significant of which is that we cannot differentiate between an array of points, and a point itself in the case of a column with the `point[]` type. The attributes API gives us a reasonable way to have a proper deprecation cycle for this change, so let's take advantage of it. If we like this change, we can also add proper support for the other geometric types (line, lseg, box, path, polygon, and circle), all of which are just aliases for string today. Fixes #20441
-
- 31 5月, 2015 4 次提交
-
-
由 Yves Senn 提交于
-
由 Sean Griffin 提交于
Our general contract in Active Record is that strings are assumed to be SQL literals, and symbols are assumed to reference a column. If a from clause is given, we shouldn't include the table name, but we should still quote the value as if it were a column. Upon fixing this, the tests were still failing on SQLite. This was because the column name being returned by the query was `"\"join\""` instead of `"join"`. This is actually a bug in SQLite that was fixed a long time ago, but I was using the version of SQLite included by OS X which has this bug. Since I'm guessing this will be a common case for contributors, I also added an explicit check with a more helpful error message. Fixes #20360
-
由 Sean Griffin 提交于
-
由 Ryuta Kamizono 提交于
-
- 28 5月, 2015 3 次提交
-
-
由 Shane Hender 提交于
-
由 Akshay Vishnoi 提交于
-
由 George Claghorn 提交于
Currently, values for columns backing Active Record enums must be specified as integers in test fixtures: awdr: title: "Agile Web Development with Rails" status: 2 rfr: title: "Ruby for Rails" status: <%= Book.statuses[:proposed] %> This is potentially confusing, since enum values are typically specified as symbols or strings in application code. To resolve the confusion, this change permits the use of symbols or strings to specify enum values: awdr: status: :published It is compatible with fixtures that specify enum values as integers.
-
- 26 5月, 2015 2 次提交
-
-
由 keepcosmos 提交于
-
由 Yves Senn 提交于
See #9683 for the reasons we switched to `distinct`. Here is the discussion that triggered the actual deprecation #20198. `uniq`, `uniq!` and `uniq_value` are still around. They will be removed in the next minor release after Rails 5.
-
- 16 5月, 2015 1 次提交
-
-
由 Prathamesh Sonpatki 提交于
-
- 13 5月, 2015 1 次提交
-
-
由 Alex Coomans 提交于
Add full set of MySQL CLI options to support SSL authentication when using db:structure dump and load
-
- 11 5月, 2015 1 次提交
-
-
由 Alex Robbin 提交于
If your STI class looks like this: ```ruby class Company < ActiveRecord::Base self.store_full_sti_class = false class GoodCo < Company end class BadCo < Company end end ``` The expectation (which is valid) is that the `type` in the database is saved as `GoodCo` or `BadCo`. However, another expectation should be that setting `type` to `GoodCo` would correctly instantiate the object as a `Company::GoodCo`. That second expectation is what this should fix.
-
- 04 5月, 2015 1 次提交
-
-
由 Ryuta Kamizono 提交于
Example: create_table :foos do |t| t.string :string_en, collation: 'en_US.UTF-8' t.text :text_ja, collation: 'ja_JP.UTF-8' end
-
- 03 5月, 2015 2 次提交
-
-
由 Ryuta Kamizono 提交于
If the adapter supports indexes in create table, generated SQL is slightly more efficient.
-
由 Ryuta Kamizono 提交于
-
- 01 5月, 2015 1 次提交
-
-
由 thiagoaugusto 提交于
-
- 27 4月, 2015 1 次提交
-
- 22 4月, 2015 1 次提交
-
-
由 Yves Senn 提交于
-
- 21 4月, 2015 1 次提交
-
-
由 Andrew White 提交于
In 1f006c an option was added called :class to allow passing anonymous classes to association definitions. Since using :class instead of :class_name is a fairly common typo even amongst experienced developers this can result in hard to debug errors arising in raise_on_type_mismatch? To fix this we're renaming the option from :class to :anonymous_class as that is a more correct description of what the option is for. Since this was an internal, undocumented option there is no need for a deprecation. Fixes #19659
-
- 18 4月, 2015 1 次提交
-
-
由 Sean Griffin 提交于
To me it seems like this should only be the case if `autosave: true` is set on the association. However, when implemented that way, it caused issues with has many associations, where we have explicit tests stating that child records are updated when the parent is new, even if autosave is not set (presumably to update the parent id, but other changed attributes would be persisted as well). It's quirky, but at least we should be consistently quirky. This constitutes a minor but subtle change in behavior, and therefore should not be backported to 4.2 and earlier. Fixes #19782
-
- 15 4月, 2015 2 次提交
-
-
由 Paul Mucur 提交于
The `index` option used with `timestamps` should be passed to both `column` definitions for `created_at` and `updated_at` rather than just the first. This was happening because `Hash#delete` is used to extract the `index` option passed to `timestamps`, thereby mutating the `options` hash in-place. Now take a copy of the `options` before deleting so that the original is not modified.
-
由 Yves Senn 提交于
This reverts commit 524d4059, reversing changes made to 34d3a609. Reasoning behind the revert are in the PR discussion: https://github.com/rails/rails/pull/19755 - This means that types can no longer cast to/from `Set`, and reasonably work with `where` (we already have this problem for `array`/`json` types on pg) - This adds precedent for every other `Enumerable`, and we can't target `Enumerable` directly. - Calling `to_a` on a `Set` is reasonable.
-
- 14 4月, 2015 1 次提交
-
-
由 Yuki Nishijima 提交于
Previously `#where` used to treat `Set`objects as nil, but now it treats them as an array: set = Set.new([1, 2]) Author.where(:id => set) # => SELECT "authors".* FROM "authors" WHERE "authors"."id" IN (1, 2)
-
- 13 4月, 2015 1 次提交
-
-
由 Grey Baker 提交于
Fixes #18106
-
- 09 4月, 2015 1 次提交
-
-
由 Andrey Voronkov 提交于
-
- 30 3月, 2015 1 次提交
-
-
由 Sean Griffin 提交于
We were never clearing the `PG::Result` object used to query the types when the connection is first established. This would lead to a potentially large amount of memory being retained for the life of the connection. Investigating this issue also revealed several low hanging fruit on the performance of these methods, and the number of allocations has been reduced by ~90%. Fixes #19578
-
- 26 3月, 2015 1 次提交
-
-
由 Jason Nochlin 提交于
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.
-
- 23 3月, 2015 2 次提交
-
-
由 Matthew Draper 提交于
The subtype will (quite reasonably) ignore the possibility that it has `changed_in_place?` by becoming nil. Fixes #19467
-
由 Carlos Antonio da Silva 提交于
-
- 22 3月, 2015 2 次提交
-
-
由 pinglamb 提交于
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.
-
由 wallerjake 提交于
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
-
- 19 3月, 2015 2 次提交
- 18 3月, 2015 1 次提交
-
-
由 Ryan Wallace 提交于
Fixes db:structure:dump when using schema_search_path and PostgreSQL extensions. Closes #17157.
-
- 17 3月, 2015 1 次提交
-
-
由 Brandon Weiss 提交于
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.
-
- 16 3月, 2015 1 次提交
-
-
由 Ben Woosley 提交于
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.
-