| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|/
|
|
|
|
|
|
|
|
|
|
|
| |
Follow up to #26735.
If `table_options` returns `{ comment: nil }`, `create_table` line is
broken.
Example:
```ruby
create_table "accounts", force: :cascade, do |t|
```
|
|
|
|
|
|
|
|
| |
Per discussion in pull request #26622:
"Let's change it to PG::Error. The more specific classes mentioned are
subclasses, and the fact the raised exception is a PG::UndefinedColumn
doesn't change the fact that it's also a PG::Error." - matthewd
|
|
|
|
|
| |
This clarifies the object that +ActiveRecord::Base.connection.execute+
will return when using Postgresql.
|
|
|
|
|
|
|
|
|
| |
Recently, the Rails team made an effort to keep the source code consistent, using Ruboco
(bb1ecdcc677bf6e68e0252505509c089619b5b90 and below). Some of the case
statements were missed.
This changes the case statements' formatting and is consistent with changes
in 810dff7c9fa9b2a38eb1560ce0378d760529ee6b and db63406cb007ab3756d2a96d2e0b5d4e777f8231.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
| |
Fixes #26137.
|
|
|
|
|
| |
Because `sql_for_insert` is only called in `use_insert_returning?` is
true since #26002.
|
|\
| |
| |
| |
| | |
kamipo/sql_for_insert_should_be_called_inside_exec_insert
`sql_for_insert` should be called inside `exec_insert`
|
| |
| |
| |
| |
| | |
`exec_insert` cannot return last inserted id if `use_insert_returning?`
is true. `sql_for_insert` should be called inside `exec_insert`.
|
| |
| |
| |
| |
| |
| |
| |
| | |
Style/SpaceBeforeBlockBraces
Style/SpaceInsideBlockBraces
Style/SpaceInsideHashLiteralBraces
Fix all violations in the repository.
|
| | |
|
| | |
|
|/
|
|
|
| |
The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.
|
|
|
|
|
|
| |
`insert`, `update`, `delete`, and `exec_query` have a default value
against `name` and `binds`. But `exec_insert`, `exec_update`, and
`exec_delete` not have. It is an inconvenience and inconsistent.
|
|\
| |
| | |
Prevent `table_comment` query if a table doesn't have a comment
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Caching a mutable string causes the following issue.
```
Loading development environment (Rails 5.1.0.alpha)
irb(main):001:0> ActiveRecord::Base.connection.quote_table_name('foo') << '!!'
=> "`foo`!!"
irb(main):002:0> ActiveRecord::Base.connection.quote_table_name('foo') << '!!'
=> "`foo`!!!!"
irb(main):003:0> ActiveRecord::Base.connection.quote_table_name('foo') << '!!'
=> "`foo`!!!!!!"
```
|
| |
| |
| |
| |
| | |
Where appropriatei, prefer the more concise Regexp#match?,
String#include?, String#start_with?, or String#end_with?
|
|\ \
| | |
| | |
| | |
| | | |
kamipo/move_warning_about_composite_primary_key_to_attribute_methods_primary_key
Move the warning about composite primary key to `AttributeMethods::PrimaryKey`
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Actually schema dumper/creation supports composite primary key (#21614).
Therefore it should not show the warning about composite primary key in
connection adapter.
This change moves the warning to `AttributeMethods::PrimaryKey` and
suppress the warning for habtm join table.
Fixes #25388.
|
|/ /
| |
| |
| | |
`ActiveRecord::ConnectionAdapters::PostgreSQL::SchemaStatements#default_sequence_name`
|
|\ \
| | |
| | |
| | |
| | | |
kamipo/extract_foreign_key_action_from_information_schema
Extract foreign key action from `information_schema`
|
| |/ |
|
|/
|
|
| |
Fixes #25391
|
|
|
|
| |
as value
|
|
|
|
|
|
| |
Follow up of 1683410.
Signed-off-by: Jeremy Daer <jeremydaer@gmail.com>
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Example:
create_table :users do |t|
t.string :name
t.index 'lower(name) varchar_pattern_ops'
end
Fixes #19090.
Fixes #21765.
Fixes #21819.
Fixes #24359.
Signed-off-by: Jeremy Daer <jeremydaer@gmail.com>
|
|
|
|
| |
`IPAddr` is used in `OID::Cidr`.
|
|
|
|
| |
Follow up to 1683410.
|
|\
| |
| |
| | |
Primary key should be `NOT NULL`
|
| |
| |
| |
| |
| |
| |
| | |
Follow up to #18228.
In MySQL and PostgreSQL, primary key is to be `NOT NULL` implicitly.
But in SQLite it must be specified `NOT NULL` explicitly.
|
| |
| |
| |
| |
| |
| | |
* Switch to keyword args where we can without breaking compat.
* Use add_table_options! for :options, too.
* Some code polish.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Comments are specified in migrations, stored in database itself (in its schema),
and dumped into db/schema.rb file.
This allows to generate good documentation and explain columns and tables' purpose
to everyone from new developers to database administrators.
For PostgreSQL and MySQL only. SQLite does not support comments at the moment.
See docs for PostgreSQL: http://www.postgresql.org/docs/current/static/sql-comment.html
See docs for MySQL: http://dev.mysql.com/doc/refman/5.7/en/create-table.html
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
- we are ending sentences properly
- fixing of space issues
- fixed continuity issues in some sentences.
Reverts https://github.com/rails/rails/commit/8fc97d198ef31c1d7a4b9b849b96fc08a667fb02 .
This change reverts making sure we add '.' at end of deprecation sentences.
This is to keep sentences within Rails itself consistent and with a '.' at the end.
|
|/ |
|
|\
| |
| | |
Extract `default_primary_key?` to refactor `column_spec_for_primary_key`
|
| | |
|
|\ \
| | |
| | | |
Dump `bigint` instead of `integer` with `limit: 8` for schema dumper
|
| |/
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Before:
```ruby
create_table "big_numbers", force: :cascade do |t|
t.integer "bigint_column", limit: 8
end
```
After:
```ruby
create_table "big_numbers", force: :cascade do |t|
t.bigint "bigint_column"
end
```
|
|\ \
| |/
|/| |
Passing `table_name` to `Column#initialize` to avoid `instance_variable_set`
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| | |
working
Currently the results of `column.serial?` is not correct. For
`column.serial?` correctly working, initialize `column.table_name`
immediately.
|
|\ \
| |/
|/| |
Fix bigserial appears with limit 8 for schema dumper
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Before:
```ruby
create_table "postgresql_big_serials", force: :cascade do |t|
t.bigserial "seq", limit: 8, null: false
end
```
After:
```ruby
create_table "postgresql_big_serials", force: :cascade do |t|
t.bigserial "seq", null: false
end
```
|
|/
|
|
| |
Currently column options handled by the type map in Rails 4.2.
|
|
|
|
| |
Actually `:name` and `:type` are not column options.
|
|
|
|
|
|
|
|
| |
habtm join tables commonly have two id columns and it's OK to make those
two id columns a primary key. This commit eliminates the warnings for
join tables that have this setup.
ManageIQ/manageiq#6713
|
|
|
|
|
|
|
|
|
| |
A return value of `schema_type` is used by:
1. primary key type: using as `symbol.inspect`
2. normal column type: using as `symbol.to_s`
It is better to return symbol.
|