| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
| |
p PostgreSQLAdapter::OID::Money.precision
# => 19
p PostgreSQLAdapter::OID::Money.new.precision
# => nil
|
|
|
|
|
|
|
| |
This reverts commit ff835f90800a3e4122d64606cb328908c2e0e071, reversing
changes made to c4d85dfbc71043e2a746acd310e32f4f04db801a.
Reason: This broke the tests. We will add back after investigated.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is an alternate implementation to #22875, that generalizes a lot of
the logic that type decorators are going to need, in order to have them
work with arrays, ranges, etc. The types have the ability to map over a
value, with the default implementation being to just yield that given
value. Array and Range give more appropriate definitions.
This does not automatically make ranges time zone aware, as they need to
be added to the `time_zone_aware` types config, but we could certainly
make that change if we feel it is appropriate. I do think this would be
a breaking change however, and should at least have a deprecation cycle.
Closes #22875.
/cc @matthewd
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Timestamp column can have less precision than ruby timestamp
In result in how big a fraction of a second can be stored in the
database.
m = Model.create!
m.created_at.usec == m.reload.created_at.usec
# => false
# due to different seconds precision in Time.now and database column
If the precision is low enough, (mysql default is 0, so it is always low
enough by default) the value changes when model is reloaded from the
database. This patch fixes that issue ensuring that any timestamp
assigned as an attribute is converted to column precision under the
attribute.
|
|
|
|
| |
Generic cast-to-text was only added in 8.3.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Several changes were made in #21110 which I am strongly opposed to.
(this is what I get for going on vacation. :trollface:) No type should
be introduced into the generic `ActiveRecord::Type` namespace, and
*certainly* should not be registered into the registry unconstrained
unless it is supported by *all* adapters (which basically means that it
was specified in the ANSI SQL standard).
I do not think `# :nodoc:` ing the type is sufficient, as it still makes
the code of Rails itself very unclear as to what the role of that class
is. While I would argue that this shouldn't even be a super class, and
that MySql and PG's JSON types are only superficially duplicated (they
might look the same but will change for different reasons in the
future).
However, I don't feel strongly enough about it as a point of contention
(and the biggest cost of harming the blameability has already occured),
so I simply moved the superclass into a namespace where its role is
absolutely clear.
After this change, `attribute :foo, :json` will once again work with
MySQL and PG, but not with Sqlite3 or any third party adapters.
Unresolved questions
--------------------
The types that and adapter publishes (at least those are unique to that
adapter, and not adding additional behavior like `MysqlString` should
probably be part of the adapter's public API. Should we standardize the
namespace for these, and document them?
|
|
|
|
|
|
|
|
|
|
| |
As of MySQL 5.7.8, MySQL supports a native JSON data type.
Example:
create_table :json_data_type do |t|
t.json :settings
end
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
This obsoletes the ruby based implementations.
|
|
|
|
|
|
|
|
|
|
| |
The type map was introduced in aafee23, but wasn't properly filled.
This mainly adjusts many locations, that expected strings instead of
integers or boolean.
add_pg_decoders is moved after setup of the StatementPool, because
execute_and_clear could potentially make use of it.
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
Fixes #19389.
|
|
|
|
|
|
|
|
|
| |
This helper no longer makes sense as a separate method. Instead I'll
just have `deserialize` call `cast` by default. This led to a random
infinite loop in the `JSON` pg type, when it called `super` from
`deserialize`. Not really a great way to fix that other than not calling
super, or continuing to have the separate method, which makes the public
API differ from what we say it is.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
| |
The latest version of the PG gem can actually convert the primitives for
us in C code, which gives a pretty substantial speed up. A few cases
were only there to add the `infinity` method, which I just put on the
range type (which is the only place it was used). Floats also needed to
parse `Infinity` and `NaN`, but it felt reasonable enough to put that on
the generic form.
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
| |
If timestamp column have the precision, it need to format according to
the precision of timestamp column.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This predicate was only to figure out if it's safe to do case
insensitive comparison, which is only a problem on PG. Turns out, PG can
just tell us whether we are able to do it or not. If the query turns out
to be a problem, let's just replace that method with checking the SQL
type for `text` or `character`. I'd rather not burden the type objects
with adapter specific knowledge.
The *real* solution, is to deprecate this behavior entirely. The only
reason we need it is because the `:case_sensitive` option for
`validates_uniqueness_of` is documented as "this option is ignored for
non-strings". It makes no sense for us to do that. If the type can't be
compared in a case insensitive way, the user shouldn't tell us to do
case insensitive comparison.
|
|
|
|
|
|
|
| |
The type code is actually quite accessible, and I'm planning to
encourage people to look at the files in the `type` folder to learn more
about how it works. This will help reduce the noise from code that is
less about type casting, and more about random AR nonsense.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The same is not true of `define_attribute`, which is meant to be the low
level no-magic API that sits underneath. The differences between the two
APIs are:
- `attribute`
- Lazy (the attribute will be defined after the schema has loaded)
- Allows either a type object or a symbol
- `define_attribute`
- Runs immediately (might get trampled by schema loading)
- Requires a type object
This was the last blocker in terms of public interface requirements
originally discussed for this feature back in May. All the
implementation blockers have been cleared, so this feature is probably
ready for release (pending one more look-over by me).
|
|
|
|
|
|
|
| |
Keeping with our behavior elsewhere in the system, invalid input is
assumed to be `nil`.
Fixes #18629.
|
|
|
|
|
|
| |
The types that are affected by `time_zone_aware_attributes` (which is on
by default) have been made configurable, in case this is a breaking
change for existing applications.
|
|
|
|
| |
addresses https://github.com/rails/rails/commit/91949e48cf41af9f3e4ffba3e5eecf9b0a08bfc3#commitcomment-9144563
|
|
|
|
|
|
|
|
|
|
| |
This showed up when running BinaryTest#test_load_save with the more
restrictive input string handling of pg-0.18.0.pre20141117110243.gem .
Bytea values sent to the server are in binary format, but are
returned back as escaped text. To fulfill the assumption that
type_cast_from_database(type_cast_for_database(binary)) == binary
we unescape only, if the value was really received from the server.
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The current style for warning messages without newlines uses
concatenation of string literals with manual trailing spaces
where needed.
Heredocs have better readability, and with `squish` we can still
produce a single line.
This is a similar use case to the one that motivated defining
`strip_heredoc`, heredocs are super clean.
|
|
|
|
| |
[ci skip]
|
|
|
|
|
|
|
|
|
|
| |
Using heredoc would enforce line wrapping to whatever column width we decided to
use in the code, making it difficult for the users to read on some consoles.
This does make the source code read slightly worse and a bit more error-prone,
but this seems like a fair price to pay since the primary purpose for these
messages are for the users to read and the code will not stick around for too
long.
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
The method has been removed in 09206716f8695f6b8467f15c1befa5a4c3c10978
(PR #16074), but the delegation was apparently missed, and one instance
of the method was added back with the addition of OID::Xml in
336be2bdf7dfa1b31879d0ab27e5f3101b351923 (PR #16072), so we can safely
rm both.
|
|
|
|
| |
[Philippe Creux, Chris Teague]
|
| |
|
| |
|
|\
| |
| | |
Don't rely on the sql type to quote XML columns in PG
|
| | |
|
|/
|
|
|
|
|
| |
This was only used for uniqueness validations. The first usage was in
conjunction with `limit`. Types which cast to string, but are not
considered text cannot have a limit. The second case was only with an
explicit `:case_sensitive => true` option given by the user.
|
| |
|
|\
| |
| | |
Do not rely on the column type when quoting infinity
|