aboutsummaryrefslogtreecommitdiffstats
path: root/activerecord/lib/active_record/connection_adapters/postgresql/oid
Commit message (Collapse)AuthorAgeFilesLines
* Enforce frozen string in RubocopKir Shatrov2017-07-0122-0/+22
|
* Consolidate database specific JSON types to `Type::Json`Ryuta Kamizono2017-05-302-2/+2
|
* Deserialize a raw value from the database in `changed_in_place?` for ↵Ryuta Kamizono2017-05-301-10/+0
| | | | | | | | `AbstractJson` Structured type values sometimes caused representation problems (keys sort order, spaces, etc). A raw value from the database should be deserialized (normalized) to prevent the problems.
* [PostgreSQL]: Replace deprecated PG constants.Lars Kanis2017-03-221-1/+1
| | | | | The old top level classes PGconn, PGresult and PGError were deprecated since pg-0.13.0: https://github.com/ged/ruby-pg/blob/master/History.rdoc#v0130-2012-02-09-michael-granger-gedfaeriemudorg
* Fix `deserialize` with JSON arrayRyuta Kamizono2017-03-061-1/+1
| | | | Fixes #28285.
* Schema dumping support for PostgreSQL oid typeRyuta Kamizono2017-02-121-0/+13
| | | | Closes #27980
* Schema dumping support for PostgreSQL interval typeRyuta Kamizono2017-02-121-1/+2
| | | | Closes #27979
* Remove unneeded requires at active recordRafael Mendonça França2017-01-031-2/+0
|
* Compare deserialized values for `PostgreSQL::OID::Hstore` typesJon Moss2017-01-031-0/+8
| | | | | | | | | | | | | Per the regression commit below, the commit changes the behavior of `#changed?`to consult the `#changed_in_place?` method on `Type::Value` classes. Per this change, `PostgreSQL::OID::Hstore` needs to override this method in order to compare the deserialized forms of the two arguments. In Ruby, two hashes are considered equal even if their key order is different. This commit helps to bring that behavior to `Hstore` values. Fixes regression introduced by 8e633e505880755e7e366ccec2210bbe2b5436e7 Fixes #27502
* 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.
* Describe what we are protectingAkira Matsuda2016-12-231-0/+2
|
* Merge pull request #27076 from y-yagi/fix_postgresql_array_encodingSean Griffin2016-11-171-1/+1
|\ | | | | use `force_encoding` instread of `encode!` to avoid `UndefinedConversionError`
| * 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
* | Support AC::Parameters for PG HStoreJon Moss2016-11-151-0/+2
|/ | | | | | | | | | | | | | | As reported via #26904, there is a regression in how values for Postgres' HStore column type are being processed, beginning in Rails 5. Currently, the way that Active Record checks whether or not values need to be serialized and put into the correct storage format is whether or not it is a `Hash` object. Since `ActionController::Parameters` no longer inherits from `Hash` in Rails 5, this conditional now returns false. To remedy this, we are now checking to see whether the `value` parameters being passed in responds to a certain method, and then calling the `serialize` method, except this time with a real Hash object. Keeping things DRY! Fixes #26904.
* Add more rubocop rules about whitespacesRafael Mendonça França2016-10-291-2/+2
|
* Use Regexp#match? rather than Regexp#===Ryuta Kamizono2016-10-261-2/+2
| | | | Follow up to 99cf7558000090668b137085bfe6bcc06c4571dc.
* Remove deprecated handling of PG PointsSean Griffin2016-08-312-18/+29
| | | | | | | | | | There are some minor changes to the point type as I had forgotten that this will affect the behavior of `t.point` in migrations and the schema dumper so we need to handle those as well. I'll say this again so I can convince myself to come up with a better structure... TYPES SHOULD NOT CARE ABOUT SCHEMA DUMPING AND WE NEED TO BETTER SEPARATE THESE.
* 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.
* Fix `OID::Bit#cast_value`Ryuta Kamizono2016-08-201-2/+2
| | | | Fixes #26137.
* normalizes indentation and whitespace across the projectXavier Noria2016-08-068-103/+103
|
* applies new string literal convention in activerecord/libXavier Noria2016-08-069-39/+39
| | | | | The current code base is not uniform. After some discussion, we have chosen to go with double quotes by default.
* Rails 5.1 point type should not raise exception if empty string is provided ↵bUg2016-05-151-0/+2
| | | | as value
* Move `require 'ipaddr'` in `postgresql/oid/cidr.rb`Ryuta Kamizono2016-04-241-0/+2
| | | | `IPAddr` is used in `OID::Cidr`.
* `OID::Money.precision` is unused since #15239Ryuta Kamizono2016-01-311-2/+0
| | | | | | | | p PostgreSQLAdapter::OID::Money.precision # => 19 p PostgreSQLAdapter::OID::Money.new.precision # => nil
* Revert "Merge pull request #23346 from kamipo/refactor_oid_money_precision"Rafael Mendonça França2016-01-301-4/+2
| | | | | | | This reverts commit ff835f90800a3e4122d64606cb328908c2e0e071, reversing changes made to c4d85dfbc71043e2a746acd310e32f4f04db801a. Reason: This broke the tests. We will add back after investigated.
* Refactor `OID::Money.precision`Ryuta Kamizono2016-01-301-2/+4
|
* Refactor tz aware types, add support for PG rangesSean Griffin2016-01-082-1/+12
| | | | | | | | | | | | | | | | | 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
* Fixed taking precision into count when assigning a value to timestamp attributeBogdan Gusiev2015-09-231-11/+7
| | | | | | | | | | | | | | | | | 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.
* Correct query for PostgreSQL 8.2Matthew Draper2015-09-081-1/+1
| | | | Generic cast-to-text was only added in 8.3.
* JSON is still an adapter specific type.Sean Griffin2015-08-212-1/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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?
* Add a native JSON data type support in MySQLRyuta Kamizono2015-08-182-36/+1
| | | | | | | | | | 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
* 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.
* Return a `Point` object from the PG Point typeSean Griffin2015-06-051-0/+50
| | | | | | | | | | | | | | | | | | | 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
* Fixed typos in guidemanish-shrivastava2015-06-011-1/+1
|
* Reduce memory usage when loading types in PGSean Griffin2015-03-291-4/+16
| | | | | | | | | | | | | 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
* 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.
* PostgreSQL, Fix OID based type casts in C for primitive types.Lars Kanis2015-03-251-1/+1
| | | | | | | | | | 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.
* 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
* Don't cast nil to string in pg enumsSean Griffin2015-03-191-1/+3
| | | | Fixes #19389.
* Rm `Type#type_cast`Sean Griffin2015-02-176-8/+8
| | | | | | | | | 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.
* `type_cast_from_user` -> `cast`Sean Griffin2015-02-171-2/+2
|
* `type_cast_for_database` -> `serialize`Sean Griffin2015-02-1710-12/+12
|
* `Type#type_cast_from_database` -> `Type#deserialize`Sean Griffin2015-02-177-8/+8
|
* Remove an unused option that I didn't mean to commit [ci skip]Sean Griffin2015-02-111-2/+1
|
* Remove most PG specific type subclassesSean Griffin2015-02-119-74/+14
| | | | | | | | | 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.
* Refactor microsecond precision to be database agnosticSean Griffin2015-02-101-9/+0
| | | | | | | | | | 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.
* Fix rounding problem for PostgreSQL timestamp columnRyuta Kamizono2015-02-081-0/+9
| | | | | If timestamp column have the precision, it need to format according to the precision of timestamp column.
* rm `Type#text?`Sean Griffin2015-02-071-4/+0
| | | | | | | | | | | | | | | | 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.
* Move non-type objects into the `Type::Helpers` namespaceSean Griffin2015-02-074-4/+4
| | | | | | | 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.
generated by cgit v1.2.3 (git 2.25.1) at 2024-07-08 23:35:51 +0000