| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |
|
|
|
|
|
| |
It doesn't make sense for the subclass to implement this method, and not
have it on the parent. We can also DRY up the implementation of
`#lookup` to be defined in terms of fetch, which will give us a single
point of entry
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
| |
We had accidentally gone one power of two too far. In addition, we need
to handle minimum values as well as the maximum.
|
| |
|
|
|
| |
When I defines large precision column at RDBMS,
I assigns float value, raise ArgumentError (precision too large).
|
| | |
|
| | |
|
| | |
|
|
|
`ActiveRecord::ConnectionAdapters::Type::Value` =>
`ActiveRecord::Type::Value`
|
