- 25 3月, 2015 3 次提交
-
-
由 Lars Kanis 提交于
This obsoletes the ruby based implementations.
-
由 Lars Kanis 提交于
The type map was introduced in aafee233, 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.
-
由 Lars Kanis 提交于
Ruby-pg's default way to serialize values for transmission to the database is to call #to_s . This however creates a temporary String object for each value. Setting a class based type map avoids the allocation of this additional String. The performance benefit is measurable in microbenchmarks, but not with the overhead of activerecord. However it's free to use and has no drawback.
-
- 12 3月, 2015 1 次提交
-
-
由 Matt Brictson 提交于
Versions of the pg gem earlier than 0.18.0 cannot be used safely with Ruby 2.2. Specifically, pg 0.17 when used with Ruby 2.2 has a known bug that causes random bits to be added to the end of strings. Further explanation here: https://bitbucket.org/ged/ruby-pg/issue/210/crazy-bytes-being-added-to-record
-
- 04 3月, 2015 2 次提交
-
-
由 Ryuta Kamizono 提交于
-
由 Ryuta Kamizono 提交于
-
- 20 2月, 2015 1 次提交
-
-
由 Ryuta Kamizono 提交于
-
- 19 2月, 2015 1 次提交
-
-
由 Ryuta Kamizono 提交于
The cause by which the test suite for the mysql adapter broke in 1502caef (reverted 89ba5bb4) is because the precision was not extracted. The rounding problem in mysql adapter has not been fixed, but `mysql_56` helper tested only mysql2 adapter, its behavior was not apparent.
-
- 18 2月, 2015 1 次提交
-
-
由 Sean Griffin 提交于
This reverts commit 1502caef. The test suite for the mysql adapter broke when this commit was used with MySQL 5.6. Conflicts: activerecord/CHANGELOG.md
-
- 16 2月, 2015 1 次提交
-
-
由 Sean Griffin 提交于
We do this in the adapter classes specifically, so the types aren't registered if we don't use that adapter. Constants under the PostgreSQL namespace for example are never loaded if we're using mysql.
-
- 12 2月, 2015 1 次提交
-
-
由 Ryuta Kamizono 提交于
-
- 11 2月, 2015 1 次提交
-
-
由 Sean Griffin 提交于
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.
-
- 08 2月, 2015 1 次提交
-
-
由 Sean Griffin 提交于
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.
-
- 04 2月, 2015 1 次提交
-
-
由 Sean Griffin 提交于
The type from the column is never used, except when being passed to the attributes API. While leaving the type on the column wasn't necessarily a bad thing, I worry that it's existence there implies that it is something which should be used. During the design and implementation process of the attributes API, there have been plenty of cases where getting the "right" type object was hard, but I had easy access to the column objects. For any contributor who isn't intimately familiar with the intents behind the type casting system, grabbing the type from the column might easily seem like the "correct" thing to do. As such, the goal of this change is to express that the column is not something that should be used for type casting. The only places that are "valid" (at the time of this commit) uses of acquiring a type object from the column are fixtures (as the YAML file is going to mirror the database more closely than the AR object), and looking up the type during schema detection to pass to the attributes API Many of the failing tests were removed, as they've been made obsolete over the last year. All of the PG column tests were testing nothing beyond polymorphism. The Mysql2 tests were duplicating the mysql tests, since they now share a column class. The implementation is a little hairy, and slightly verbose, but it felt preferable to going back to 20 constructor options for the columns. If you are git blaming to figure out wtf I was thinking with them, and have a better idea, go for it. Just don't use a type object for this.
-
- 28 1月, 2015 1 次提交
-
-
由 Sean Griffin 提交于
`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.
-
- 10 1月, 2015 1 次提交
-
-
由 Sebastian Staudt 提交于
-
- 04 1月, 2015 1 次提交
-
-
由 Ryuta Kamizono 提交于
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.
-
- 03 1月, 2015 1 次提交
-
-
由 Ryuta Kamizono 提交于
In most cases, `create_table_definition` called by table_name (the first argument) only.
-
- 29 12月, 2014 1 次提交
-
-
由 Ryuta Kamizono 提交于
If it is not a default primary key, correctly dump the type and options.
-
- 23 12月, 2014 1 次提交
-
-
由 Sean Griffin 提交于
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]
-
- 06 12月, 2014 1 次提交
-
-
由 Sean Griffin 提交于
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
-
- 02 12月, 2014 1 次提交
-
-
由 Yves Senn 提交于
-
- 01 12月, 2014 1 次提交
-
-
由 Guo Xiang Tan 提交于
Fixes: https://github.com/rails/rails/issues/17856.
-
- 21 11月, 2014 1 次提交
-
-
由 claudiob 提交于
I grepped the source code for code snippets wrapped in backticks in the comments and replaced the backticks with plus signs so they are correctly displayed in the Rails documentation. [ci skip]
-
- 20 11月, 2014 1 次提交
-
-
由 Sean Griffin 提交于
This reverts commit da99a2a2.
-
- 17 11月, 2014 1 次提交
-
-
由 Sam 提交于
-
- 14 11月, 2014 1 次提交
-
-
由 Aaron Patterson 提交于
also increase the version of pg required so that people will get the GVL friendly version
-
- 05 11月, 2014 1 次提交
-
-
由 Ted O'Meara 提交于
-
- 02 11月, 2014 1 次提交
-
-
由 Sean Griffin 提交于
MySQL reports the column name as `"MAX(developer_id)"`. PG will report it as `"max"`
-
- 30 10月, 2014 2 次提交
-
-
由 claudiob 提交于
-
由 Aaron Patterson 提交于
-
- 21 10月, 2014 1 次提交
-
-
由 claudiob 提交于
The `select` method has the same definition in almost all database adapters, so it can be moved from the database-specific adapters (PostgreSQl, MySQL, SQLite) to the abstract `database_statement`: ```ruby def select(sql, name = nil, binds = []) exec_query(sql, name, binds) end ``` --- More details about this commit: the only two DB-specific adapters that have a different definition of `select` are MySQLAdapter and MySQL2Adapter. In MySQLAdapter, `select` invokes `exec_query(sql, name, binds)`, so calling `super` achieves the same goal with less repetition. In MySQL2Adapter, `select` invokes `exec_query(sql, name)`, that is, it does not pass the `binds` parameter like other methods do. However, [MySQL2Adapter's `exec_query`](https://github.com/rails/rails/blob/74a527cc63ef56f3d0a42cf638299958dc7cb08c/activerecord/lib/active_record/connection_adapters/mysql2_adapter.rb#L228L231) works exactly the same whether this parameters is passed or not, so the output does not change: ```ruby def exec_query(sql, name = 'SQL', binds = []) result = execute(sql, name) ActiveRecord::Result.new(result.fields, result.to_a) end ```
-
- 16 10月, 2014 1 次提交
-
-
由 Aaron Patterson 提交于
In the DSL you can now do: create_table(:foos) do |t| t.bigint :hi end
-
- 23 9月, 2014 1 次提交
-
-
由 Aaron Patterson 提交于
it doesn't work on SQLite3 since it doesn't support truncate, but that's OK. If you call truncate on the connection, you're now bound to that database (same as if you use hstore or any other db specific feature).
-
- 09 9月, 2014 1 次提交
-
-
由 Yves Senn 提交于
`AbstractAdapter#supports_views?` defaults to `false` so we have to turn it on in adapter subclasses. Currently the flag only controls test execution. /cc @yahonda
-
- 05 9月, 2014 1 次提交
-
-
由 Abdelkader Boudih 提交于
-
- 25 7月, 2014 1 次提交
-
-
由 Philippe Creux 提交于
[Philippe Creux, Chris Teague]
-
- 07 7月, 2014 1 次提交
-
-
由 Sean Griffin 提交于
-
- 03 7月, 2014 1 次提交
-
-
由 Rafael Mendonça França 提交于
Fix CVE-2014-3483 and protect against CVE-2014-3482.
-
- 29 6月, 2014 1 次提交
-
-
由 Sean Griffin 提交于
The only case where we got a column that was not `nil`, but did not respond to `cast_type` was when type casting the default value during schema creation. We can look up the cast type, and add that object to the column definition. Will allow us to consistently rely on the type objects for type casting in all directions.
-