The various databases don't actually need significantly different
handling for this behavior, and they can achieve it without knowing
about the type of the object.
The old implementation was returning a string, which will cause problems
such as breaking TZ aware attributes, and making it impossible for the
adapters to supply their logic for time objects.
The charset of `version` column in `schema_migrations` table is depend
on the database default charset and collation rather than the encoding
of the connection.
Remaining are `limit`, `precision`, `scale`, and `type` (the symbol
version). These will remain on the column, since they mirror the options
to the `column` method in the schema definition DSL
All columns which would map to a string primitive need this behavior.
Binary has it's own marker type, so it won't go through this conversion.
String and text, which need this, will.
Fixes#18585.
`bound_attributes` is now used universally across the board, removing
the need for the conversion layer. These changes are mostly mechanical,
with the exception of the log subscriber. Additional, we had to
implement `hash` on the attribute objects, so they could be used as a
key for query caching.
Slightly refactoring `PostgreSQLColumn`. `array` should be readonly.
`default_function` should be initialized by `super`. `sql_type` has been
removed `[]`. Since we already choose to remove it we should not change.
Incompatible to rounding behavior between MySQL 5.6 and earlier.
In 5.5, when you insert `2014-08-17 12:30:00.999999` the fractional part
is ignored. In 5.6, it's rounded to `2014-08-17 12:30:01`:
http://bugs.mysql.com/bug.php?id=68760
A few of the tests weren't testing anything of value. The IP Address
tests are testing the type, not behavior of the connection adapter.
There are two CVE regression tests which are important, but don't have a
good place to go, so I've left them alone for now, as they call `quote`
and the focus right now is removing `column` from `type_cast`
The column itself has no actual impact on the return value. These were
actually testing the behavior of the type object, which is sufficiently
covered elsewhere.
The string encoding test wasn't using the types for anything. The
boolean casting test included logic that should be in the tests for the
types, and the string test was legitimately not testing anything useful.
When table has a composite primary key, the `primary_key` method for
sqlite3 and postgresql was only returning the first field of the key.
Ensures that it will return nil instead, as AR dont support composite pks.
This will allow eager type casting to take place as needed. There
doesn't seem to be any particular reason that the `in` statement was
forced for single values, and the commit message where it was introduced
gives no context.
See
d90b4e2615
I think we should deprecate this behavior and just error if you tell us
to do a case insensitive comparison for types which are not case
sensitive. Partially reverts 35592307
Fixes#18195
If the test is interrupted in a way that the teardown block fails to
run, the tests will fail to run until the table is removed manually
without this option.
PG doesn't register it's types using the `int(4)` format that others do.
As such, if we alias `int8` to the other integer types, the range
information is lost. This is fixed by simply registering it separately.
The other option (which I specifically chose to avoid) is to pass the
information of the original type that was being aliased as an argument.
I'd rather avoid that, since an alias should truly be treated the same.
If we need different behavior for a different type, we should explicitly
register it with that, and not have a conditional based on aliasing.
Fixes#18144
[Sean Griffin & ysbaddaden]
Apparently PG does not validate against RFC 4122. The intent of the original
patch is just to protect against PG errors (which potentially breaks txns, etc)
because of bad user input, so we shouldn't try any harder than PG itself.
Closes#17931
PostgreSQL for example, allows infinity as a valid value for date time
columns. The PG type has explicit handling for that case. However, time
zone conversion will end up trampling that handling. Unfortunately, we
can't call super and then convert time zones.
However, if we get back nil from `.in_time_zone`, it's something we
didn't expect so we can let the superclass handle it.
Fixes#17971
The user is able to pass PG string literals in 4.1, and have it
converted to an array. This is also possible in 4.2, but it would remain
in string form until saving and reloading, which breaks our
`attr = save.reload.attr` contract. I think we should deprecate this in
5.0, and only allow array input from user sources. However, this
currently constitutes a breaking change to public API that did not go
through a deprecation cycle.
If the tests are interupted and the teardown block doesn't run, the
developer needs to delete these manually in order to be able to run the
tests again.
The type registration was simply looking for the OID, and eagerly
fetching/constructing the sub type when it was registered. However,
numeric types have additional parameters which are extracted from the
actual SQL string of the type during lookup, and can have their behavior
change based on the result.
We simply need to use the block form of registration, and look up the
subtype lazily instead.
Fixes#17935
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.
