aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord/lib/active_record/connection_adapters/postgresql/oid/array.rb
Commit message (Collapse)AuthorAgeFilesLines
* Use frozen-string-literal in ActiveRecordKir Shatrov2017-07-191-0/+2
|
* Revert "Merge pull request #29540 from kirs/rubocop-frozen-string"Matthew Draper2017-07-021-1/+0
| | | | | This reverts commit 3420a14590c0e6915d8b6c242887f74adb4120f9, reversing changes made to afb66a5a598ce4ac74ad84b125a5abf046dcf5aa.
* Enforce frozen string in RubocopKir Shatrov2017-07-011-0/+1
|
* Fix `deserialize` with JSON arrayRyuta Kamizono2017-03-061-1/+1
| | | | Fixes #28285.
* Consistently apply adapter behavior when serializing arraysSean Griffin2017-01-031-13/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | In f1a0fa9 we moved backend specific timestamp behavior out of the type and into the adapter. This was in line with our general attempt to reduce the number of adapter specific type subclasses. However, on PG, the array type performs all serialization, including database encoding in its serialize method. This means that we have converted the value into a string before reaching the database, so no adapter specific logic can be applied (and this also means that timestamp arrays were using the default `.to_s` method on the given object, which likely meant timestamps were being ignored in certain cases as well) Ultimately I want to do a more in depth refactoring which separates database serializer objects from the active model type objects, to give us a less awkward API for introducing the attributes API onto Active Model. However, in the short term, we follow the solution we've applied elsewhere for this. Move behavior off of the type and into the adapter, and use a data object to allow the type to communicate information up the stack. Fixes #27514.
* Dump array subtype options correctlyRyuta Kamizono2017-01-011-1/+1
| | | | | Currently schema dumper does not dump array subtype `precision` and `scale` options. This commit fixes the issue.
* use `force_encoding` instread of `encode!` to avoid `UndefinedConversionError`yuuji.yaginuma2016-11-171-1/+1
| | | | | | | | | | | | | | | `PG::TextEncoder::Array#encode` returns the encoded value with `ASCII-8BIT`. But in some cases, trying to convert `ASCII-8BIT` to `UTF-8` cause an error. ```ruby "{\xE3\x83\x95\xE3\x82\xA1\xE3\x82\xA4\xE3\x83\xAB}".encode!(Encoding::UTF_8) # => Encoding::UndefinedConversionError: "\xE3" from ASCII-8BIT to UTF-8 ``` Should use `force_encoding` to avoid this error. Follow up to 7ba3a48df5bfdc5e98506bb829f937e03b55a5b3 Ref: https://github.com/rails/rails/pull/23619#issuecomment-189924036
* Attempt to maintain encoding for arrays of strings with PGSean Griffin2016-08-311-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | I still think that this is something that should be handled in the pg gem, but it's not going to end up happening there so we'll do it here instead. Once we bump to pg 0.19 we can pass the encoding to the `encode` method instead. This issue occurs because C has no concept of encoding (or strings, really). The bytes that we pass here when sending the value to the database will always be interpreted as whatever encoding the connection is currently configured to use. That means that roundtripping to the database will lose no information However, after assigning we round trip through our type system without hitting the database. The only way that we can do the "correct" thin here would be to actually give a reference to the connection to the array type and have it check the current value of the connection's encoding -- which I'm strongly opposed to. We could also pass in the encoding when it's constructed, but since that can change independently of the type I'm not a huge fan of that either. This feels like a reasonable middle ground, where if we have an array of strings we simply use the encoding of the string we're given. Fixes #26326.
* normalizes indentation and whitespace across the projectXavier Noria2016-08-061-6/+6
|
* applies new string literal convention in activerecord/libXavier Noria2016-08-061-1/+1
| | | | | The current code base is not uniform. After some discussion, we have chosen to go with double quotes by default.
* Refactor tz aware types, add support for PG rangesSean Griffin2016-01-081-0/+4
| | | | | | | | | | | | | | | | | 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
* Correctly handle array columns with defaults in the schema dumperSean Griffin2015-06-111-0/+5
| | | | | | | | | 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.
* PostgreSQL, Use ruby-pg's built-in capabilities for array en-/decoding in C.Lars Kanis2015-03-251-50/+6
| | | | This obsoletes the ruby based implementations.
* Delegate limit to subtypewallerjake2015-03-211-1/+1
| | | | | | | | | | 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
* `type_cast_from_user` -> `cast`Sean Griffin2015-02-171-2/+2
|
* `type_cast_for_database` -> `serialize`Sean Griffin2015-02-171-2/+2
|
* `Type#type_cast_from_database` -> `Type#deserialize`Sean Griffin2015-02-171-2/+2
|
* Move non-type objects into the `Type::Helpers` namespaceSean Griffin2015-02-071-1/+1
| | | | | | | 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.
* Allow a symbol to be passed to `attribute`, in place of a type objectSean Griffin2015-02-061-0/+6
| | | | | | | | | | | | | | | | | | 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).
* Time columns should support time zone aware attributesSean Griffin2015-01-151-1/+1
| | | | | | 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.
* Revert to 4.1 behavior for casting PG arraysSean Griffin2014-12-081-0/+3
| | | | | | | | | | 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.
* add missing `:nodoc:` for recent refactorings. [ci skip]Yves Senn2014-06-241-1/+1
| | | | | | | | | | Adding `# :nodoc:` to the parent `class` / `module` is not going to ignore nested classes or modules. There is a modifier `# :nodoc: all` but sadly the containing class or module will continue to be in the docs. /cc @sgrif
* Detect mutations of arrays and array membersSean Griffin2014-06-171-12/+14
|
* Ensure `OID::Array#type_cast_for_database` matches PG's quoting behaviorSean Griffin2014-06-171-6/+20
| | | | | | Also takes a step towards supporting types which use a character other than ',' for the delimiter (`box` is the only built in type for which this is the case)
* Move array database type casting to the Array typeSean Griffin2014-06-171-0/+30
| | | | | | | | | The case where we have a column object, but don't have a type cast method involves type casting the default value when changing the schema. We get one of the column definition structs instead. That is a case that I'm trying to remove overall, but in the short term, we can achieve the same behavior without needing to pass the adapter to the array type by creating a fake type that proxies to the adapter.
* PG arrays should type cast user inputSean Griffin2014-06-131-4/+8
| | | | | | We guarantee that `model.value` does not change after `model.save && model.reload`. This requires type casting user input for non-string types.
* Inline PG array type casting helperSean Griffin2014-06-101-4/+26
|
* Move PG OID types to their own filesSean Griffin2014-05-211-0/+24
As we promote these classes to first class concepts, these classes are starting to gain enough behavior to warrant being moved into their own files. Many of them will become quite large as we move additional behavior to the type objects.
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-06 08:26:40 +0000