| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rather than having to do:
create_table :posts do |t|
t.references :user
end
add_foreign_key :posts, :users
You can instead do:
create_table :posts do |t|
t.references :user, foreign_key: true
end
Similar to the `index` option, you can also pass a hash. This will be
passed as the options to `add_foreign_key`. e.g.:
create_table :posts do |t|
t.references :user, foreign_key: { primary_key: :other_id }
end
is equivalent to
create_table :posts do |t|
t.references :user
end
add_foreign_key :posts, :users, primary_key: :other_id
|
|
|
|
|
|
| |
While we aren't taking PRs with these kinds of changes just yet, they
are fine if we're actively working on the method and it makes things
easier.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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]
|
| |
|
|
|
|
|
|
|
|
| |
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
|
|\
| |
| | |
Fix undesirable RangeError by Type::Integer. Add Type::UnsignedInteger.
|
| | |
|
|/
|
|
| |
Move microseconds formatting to `AbstractAdapter`.
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When running the following migration:
change_table(:table_name) { |t| t/timestamps }
The following error was produced:
wrong number of arguments (2 for 1) .... /connection_adapters/abstract/schema_statements.rb:851:in `remove_timestamps'
This is due to `arguments` containing an empty hash as its second
argument.
|
| |
|
|
|
|
| |
Fixes: https://github.com/rails/rails/issues/17856.
|
| |
|
|\
| |
| | |
Refactor `add_column_options!`, to move the quoting of default value for :uuid in `quote_value`.
|
| | |
|
| |
| |
| |
| | |
:uuid in `quote_value`.
|
|/ |
|
|
|
|
|
| |
Not sure how we missed this case when we moved everything else to the
`_quote` method.
|
|
|
|
|
|
|
| |
This allows us so abstract the migration from the type that is actually
used by Rails. For example, ":string" may be a varchar or something,
but the framework does that translation, and the app shouldn't need to
know.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Some comments that are meant to separate blocks of code in a file show up
on http://api.rubyonrails.org as though they were part of the documentation.
This commit hides those comments from the documentation.
Stems from the discussion with @zzak at https://github.com/voloko/sdoc/issues/79#issuecomment-64158738
[ci skip]
|
|
|
|
|
|
|
|
| |
Also checked to make sure this does not affect foreign key constraints.
(It doesn't).
Fixes #12856
Closes #14088
|
|
|
|
| |
We can't change the signature without a deprecation cycle.
|
|\
| |
| | |
Wrap code snippets in +, not backticks, in sdoc [ci skip]
|
| |
| |
| |
| |
| |
| |
| |
| | |
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]
|
|/ |
|
|
|
|
|
|
|
|
| |
This makes the following changes:
* warn if `:null` is not passed to `add_timestamps`
* `timestamps` method docs link to `add_timestamps` docs
* explain where additional options go
* adjust examples to include `null: false` (to prevent deprecation warnings)
|
|
|
|
| |
This reverts commit da99a2a2982d35f670ad9647463e09bfe9032b70.
|
| |
|
|
|
|
| |
Oh hey, we got to remove some code because of that!
|
|
|
|
|
|
| |
Arel handles this for us automatically. Updated tests, as BindParam is
no longer a subclass of SqlLiteral. We should remove the second argument
to substitute_at entirely, as it's no longer used
|
|
|
|
|
|
| |
This caused a pretty major performance regression for 4.2, as this is a
hotspot for query construction. We're still slightly slower than 4.1,
but it's much less significant.
|
| |
|
|
|
|
|
| |
also increase the version of pg required so that people will get the
GVL friendly version
|
|\
| |
| |
| | |
add a Table#name accessor like TableDefinition#name
|
| | |
|
|\ \
| |/
|/| |
remove never called method `limited_update_conditions`
|
| | |
|
|/
|
|
|
| |
- remove unused method `supports_add_column?`
- change additional restriction method to `valid_alter_table_type?`
- fix code style
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Why are people assigning booleans to string columns? >_>
We unintentionally changed the behavior on Sqlite3 and PostgreSQL.
Boolean values should cast to the database's representation of true and
false. This is 't' and 'f' by default, and "1" and "0" on Mysql. The
implementation to make the connection adapter specific behavior is hacky
at best, and should be re-visted once we decide how we actually want to
separate the concerns related to things that should change based on the
database adapter.
That said, this isn't something I'd expect to change based on my
database adapter. We're storing a string, so the way the database
represents a boolean should be irrelevant. It also seems strange for us
to give booleans special behavior at all in string columns. Why is
`to_s` not sufficient? It's inconsistent and confusing. Perhaps we
should consider deprecating in the future.
Fixes #17571
|
| |
|
|\
| |
| | |
Remove unused duplicated method `add_column_position` from AbstractMysqlAdapter.
|
| |
| |
| |
| | |
AbstractMysqlAdapter
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
MySQL reports the column name as `"MAX(developer_id)"`. PG will report
it as `"max"`
|
|\ \
| |/
|/| |
Remove redundant substitute index when constructing bind values
|