| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
| |
This reverts commit 7b82e1c77b48cb351da4e0ed6ea0bac806d4925c.
This would have removed the ability to reference a schema when using PG
|
|\
| |
| |
| |
| | |
kamipo/move_quoted_names_cache_up_to_abstract_adapter
Move `@quoted_{column|table}_names` cache up to the abstract adapter
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| | |
When prepared statements are enabled, the statement cache caches the SQL
directly, including the bind parameters. If a similar query is run later
with prepared statements disabled, we need to use a separate cache
instead of trying to share the same one.
Fixes #24351
|
| |
| |
| |
| |
| |
| |
| |
| | |
Dots have special meaning in most backends (e.g. everything except
SQLite3), as well as most methods that work with table or column names.
This isn't something that we ever explicitly supported, but there's at
least one case of somebody using this (see #24367), so we'll go through a deprecation
cycle as normal.
|
|/
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This issue occured because associations now call `where` directly, and a
dot in the key name for `where` means nested tables. For this fix, we
now pass the table name as a symbol, and do not attempt to expand
symbols containing a dot.
This is a temporary fix. I do not think we should support table names
containing a dot, as it has a special meaning in most backends, as well
as most APIs that involve table names. This commit does not include a
test, as I am going to deprecate table names containing dots in the
following commit.
Fixes #24367
|
|\
| |
| | |
Make to private the visibility of `_quote` and `_type_cast`
|
| | |
|
|\ \
| | |
| | | |
provide file name for fixture ERB
|
| | | |
|
|\ \ \
| | | |
| | | | |
Add a test case for create a record with primary key as zero
|
| | |/
| |/| |
|
|\ \ \
| |/ /
|/| | |
Update compatibility.rb
|
| | | |
|
| | | |
|
|\ \ \
| | | |
| | | | |
[ci skip] relations inside <tt> tag
|
| |/ /
| | |
| | |
| | |
| | |
| | | |
s removed
objects added
|
|/ /
| |
| |
| | |
ActiveRecord::ConnectionAdapters::SchemaStatements#add_timestamps [ci skip]
|
| | |
|
| |
| |
| |
| |
| |
| |
| | |
This reverts commit 43ccebc1db072ba0c96a67de0b3db78fd8fd0973.
This is not fixing the configuration problem since we are assigning to
the ActiveRecord::Base not the configuration. See #24303.
|
|\ \
| | |
| | | |
Move sequence value methods to Model level
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
`prefetch_primary_key?` and `next_sequence_value` methods live in the
connection level at the moment, that make sense when you are generating
the sequence from the database, in the same connection. Which is the use
case today at the Oracle and Postgres adapters.
However if you have an service that generates IDs, that has nothing to
do with the database connection, and should not be fetched from there.
Another use case, is if you want to use another connection to fetch IDs,
that would not be possible with the current implementation, however when
we move those methods to the model level, you can use a new connection
there.
Also this makes easier for gems to add behavior on those methods.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
When a proc is given as a default value, the form builder ends up
displaying `Proc#to_s` when the default is used. That's because we
didn't handle the proc until type casting. This issue technically can
occur any time that a proc is the value before type casting, but in
reality the only place that will occur is when a proc default is
provided through the attributes API, so the best place to handle this
edge case is there.
I've opted to memoize instead of just moving the `Proc#call` up, as this
made me realize that it could potentially interact very poorly with
dirty checking.
The code here is a little redundant, but I don't want to rely on how
`value_before_type_cast` is implemented in the super class, even if it's
just an `attr_reader`.
Fixes #24249
Close #24306
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Without clearing the caches afterward, removals done in migrations would
not be reflected in a separate task in the same process. That is, given
a table with a migration to remove a column, the schema cache would
still reflect that a table has that in something such as the
'db:seed' task:
`rake db:migrate db:seed`
(A common thing to do in a script for a project ala `bin/setup`)
vs
`rake db:migrate && rake db:seed`
(Two processes)
The first would not reflect that the column was removed.
The second would (cache reset).
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
I have hit this deprecation in a newly created Rails 5 application and
the suggested tip lead me to a `NoMethodError`.
It's not trivial to actually make the following work, because of the
ActiveRecord::Base class attributes setting dance in the Active Record
railtie.
config.active_record.time_zone_aware_types << :time
Decided to suggest setting it explicitly to the values we need.
[ci skip]
|
|/ /
| |
| |
| |
| |
| |
| |
| |
| | |
`RuntimeError`
The error is raised because user passed invalid version number to a public api of
`ActiveRecord`, so `ArgumentError` is more suitable.
And add a test case checking if an error is raised when unknown migration version
is passed, because these test cases are not implemented.
|
|\ \
| |/
|/|
| |
| |
| | |
kamipo/append_sql_mode_instead_of_overwriting_in_strict_mode
Append sql_mode instead of overwriting in strict mode
|
| |
| |
| |
| | |
For keep the default SQL mode.
|
|\ \
| | |
| | |
| | |
| | | |
RochesterinNYC/better-error-message-for-includes-relations-missing
Improve error message for missing relations for includes and eager_load
|
| | |
| | |
| | |
| | | |
relations
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This reverts a334425caff9b2140d5e99fcfc2eb8c4ab10bdfa.
The main reason is that now the workflow is inconsistent when using
spring.
When using spring `RAILS_ENV` is always set, so only one database is
created.
This means that in development `bin/rake db:create` and `bundle exec
rake db:create` have different results.
It also breaks the `bin/setup` script since `bin/rake db:setup
db:test:prepare` will fail.
|
| |/
|/|
| |
| | |
We should use #find_or_initialize_by and #find_or_create_by because #first_or_initialize and #first_or_create methods are not the public API
|
|\ \
| | |
| | |
| | |
| | | |
kamipo/case_sensitive_comparison_for_non_string_column
The BINARY Operator is only needed for string columns
|
| | |
| | |
| | |
| | | |
Follow up to #13040.
|
|\ \ \
| | | |
| | | | |
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
```
|
| | | | |
| | | | |
| | | | | |
The comments of add_foreign_key method was displaying incorrect constraint name.
|
| | | | |
| | | | |
| | | | |
| | | | | |
Follow up to #24079
|
| |/ / /
|/| | | |
|
|\ \ \ \
| | | | |
| | | | | |
Remove outdated comment [ci skip]
|
| |/ / /
| | | |
| | | |
| | | | |
Currently column options handled by the type map in Rails 4.2.
|
|\ \ \ \
| | | | |
| | | | | |
No need to extract a limit for a boolean type
|
| | | | | |
|