- 11 11月, 2014 1 次提交
-
-
由 Cody Cutrer 提交于
-
- 10 11月, 2014 3 次提交
-
-
由 Sammy Larbi 提交于
-
由 Sean Griffin 提交于
Why are people assigning booleans to string columns? >_> We unintentionally changed the behavior on Sqlite3 and PostgreSQL. Boolean values should cast to the database's representation of true and false. This is 't' and 'f' by default, and "1" and "0" on Mysql. The implementation to make the connection adapter specific behavior is hacky at best, and should be re-visted once we decide how we actually want to separate the concerns related to things that should change based on the database adapter. That said, this isn't something I'd expect to change based on my database adapter. We're storing a string, so the way the database represents a boolean should be irrelevant. It also seems strange for us to give booleans special behavior at all in string columns. Why is `to_s` not sufficient? It's inconsistent and confusing. Perhaps we should consider deprecating in the future. Fixes #17571
-
由 Sammy Larbi 提交于
-
- 08 11月, 2014 2 次提交
-
-
由 alfa-jpn 提交于
fixes #17495
-
由 Aaron Patterson 提交于
if you specify a default scope on a model, it will break caching. We cannot predict what will happen inside the scope, so play it safe for now. fixes #17495
-
- 07 11月, 2014 3 次提交
-
-
由 Yves Senn 提交于
-
由 Yves Senn 提交于
-
由 Franky W 提交于
Currently, there is no messages which get printed out. Convoluted system may have hooks that create other objects in which case we only fail with no messages. This commit changes this information allowing you to know which object is the one that actually raised the error.
-
- 06 11月, 2014 2 次提交
- 05 11月, 2014 1 次提交
-
-
由 Ted O'Meara 提交于
-
- 03 11月, 2014 2 次提交
-
-
由 Sean Griffin 提交于
-
由 Sean Griffin 提交于
We should not behave differently just because a class has a default scope.
-
- 02 11月, 2014 3 次提交
-
-
由 Sean Griffin 提交于
We support this behavior, but have no tests which assert that type casting actually occurs.
-
由 Sean Griffin 提交于
It was transitively relying on the vertex model being loaded
-
由 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]
-
- 01 11月, 2014 5 次提交
-
-
由 Aaron Patterson 提交于
-
由 Sean Griffin 提交于
Nothing is directly using the columns for the default values anymore. This step helps us get closer not not mutating the columns hash.
-
由 Sean Griffin 提交于
Fixes #17170
-
由 Sean Griffin 提交于
We had accidentally gone one power of two too far. In addition, we need to handle minimum values as well as the maximum.
-
由 Sean Griffin 提交于
Sufficiently large integers cause `find` and `find_by` to raise `StatementInvalid` instead of `RecordNotFound` or just returning `nil`. Given that we can't cast to `nil` for `Integer` like we would with junk data for other types, we raise a `RangeError` instead, and rescue in places where it would be highly unexpected to get an exception from casting. Fixes #17380
-
- 31 10月, 2014 1 次提交
-
-
由 Sean Griffin 提交于
Arel has changed so that `.sum` no longer aliases `SUM(the_column)` to `sum_id`. This means the type returned by the adapter will be at the key `"SUM(the_column)"`. Longer term, we should eventually be able to retain type information from the AR::Base subclasses used in joined queries
-
- 30 10月, 2014 2 次提交
-
-
由 claudiob 提交于
-
由 Aaron Patterson 提交于
-
- 29 10月, 2014 2 次提交
-
-
由 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
-
由 Sean Griffin 提交于
We were relying on hash inequality in tests
-
- 27 10月, 2014 1 次提交
-
-
由 Dan Olson 提交于
-
- 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
-
- 24 10月, 2014 1 次提交
-
-
由 Mauro George 提交于
This changes the actual exception `NoMethodError: undefined method `call' for #<ActiveRecord::Relation []>` to a `ArgumentError` when try to define a scope without a callable.
-
- 23 10月, 2014 1 次提交
-
-
由 Byron Bischoff 提交于
-
- 22 10月, 2014 1 次提交
-
-
由 Keith Gable 提交于
This fixes a regression introduced by 6cc03675. ActiveRecord, if used without Rails, always checks the "default_env" environment. This would be OK, except that Sinatra also supports environments, and it runs with {RACK|RAILS}_ENV=production. This patch adds a fallback to RAILS_ENV and RACK_ENV (and ultimately default_env) if Rails.env doesn't exist.
-
- 20 10月, 2014 3 次提交
-
-
由 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
-
由 Vipul A M 提交于
-
- 19 10月, 2014 3 次提交
-
-
由 Rafael Mendonça França 提交于
Replace (slower) block.call with (faster) yield
-
由 Zachary Scott 提交于
This reverts commit 0ab075e7.
-
由 claudiob 提交于
Performance optimization: `yield` with an implicit `block` is faster than `block.call`. See http://youtu.be/fGFM_UrSp70?t=10m35s and the following benchmark: ```ruby require 'benchmark/ips' def fast yield end def slow(&block) block.call end Benchmark.ips do |x| x.report('fast') { fast{} } x.report('slow') { slow{} } end # => fast 154095 i/100ms # => slow 71454 i/100ms # => # => fast 7511067.8 (±5.0%) i/s - 37445085 in 4.999660s # => slow 1227576.9 (±6.8%) i/s - 6145044 in 5.028356s ```
-
- 18 10月, 2014 1 次提交
-
-
由 claudiob 提交于
Performance optimization: `yield` with an implicit `block` is faster than `block.call`. See http://youtu.be/fGFM_UrSp70?t=10m35s and the following benchmark: ```ruby require 'benchmark/ips' def fast yield end def slow(&block) block.call end Benchmark.ips do |x| x.report('fast') { fast{} } x.report('slow') { slow{} } end # => fast 154095 i/100ms # => slow 71454 i/100ms # => # => fast 7511067.8 (±5.0%) i/s - 37445085 in 4.999660s # => slow 1227576.9 (±6.8%) i/s - 6145044 in 5.028356s ```
-
- 17 10月, 2014 1 次提交
-
-
由 Sean Griffin 提交于
In Rails 5.0, we'd like to change the behavior of boolean columns in Rails to be closer to Ruby's semantics. Currently we have a small set of values which are "truthy", and all others are "falsy". In Rails 5.0, we will reverse this to have a small number of values which are "falsy", and all others will become "truthy". In the interim, all values which are ambiguous must emit a deprecation warning.
-