| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
| |
Where appropriatei, prefer the more concise Regexp#match?,
String#include?, String#start_with?, or String#end_with?
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, if we generate a model while
`app/model/application_record.rb` isn't present, we'll end up with a
model with an `ActiveRecord::Base` parent _and_ a newly generated
`app/models/application_record.rb`.
While the behavior for choosing an `ActiveRecord::Base` was chosen for
an easier migration math to 5.0, generating the
`app/model/application_record.rb` file kinda contradicts with it.
In any case, I think we should decide on a behavior and stick to it.
Here, I'm changing the generated parent to always be `ApplicationRecord`
and to always create `app/model/application_record.rb` if it doesn't
exist.
|
|
|
|
| |
Follow up to 1813b29fc7632959800252f36e4b2e6ed4ac7266
|
|
|
|
|
|
|
| |
Once RubyGems 2.5.0 is required, then the duplicated files can be
removed, and symlinks can be used instead.
[ci skip]
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fixes issue #22960
When creating join tables with the command
rails g migration CreateJoinTableShowroomUser showroom:references user:references
The migration will use references to create the joins and output:
class CreateJoinTableShowroomUser < ActiveRecord::Migration
def change
create_join_table :showrooms, :users do |t|
t.references :showroom, index: true, foreign_key: true
t.references :user, index: true, foreign_key: true
end
end
end
This allows for proper refrences with indexes and foreign keys to be easily used when
adding join tables. Without `:refrences` the normal output is generated:
class CreateJoinTableShowroomUser < ActiveRecord::Migration[5.0]
def change
create_join_table :showrooms, :users do |t|
# t.index [:showroom_id, :user_id]
# t.index [:user_id, :showroom_id]
end
end
end
|
| |
|
| |
|
|
|
|
|
| |
All public methods are tasks, so we need to move it to protected
visibility.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It's pretty common for folks to monkey patch `ActiveRecord::Base` to
work around an issue or introduce extra functionality. Instead of
shoving even more stuff in `ActiveRecord::Base`, `ApplicationRecord` can
hold all those custom work the apps may need.
Now, we don't wanna encourage all of the application models to inherit
from `ActiveRecord::Base`, but we can encourage all the models that do,
to inherit from `ApplicationRecord`.
Newly generated applications have `app/models/application_record.rb`
present by default. The model generators are smart enough to recognize
that newly generated models have to inherit from `ApplicationRecord`,
but only if it's present.
|
| |
|
| |
|
|
|
|
| |
Also move the method to the right class
|
| |
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Changes `rails g model Post user:references` from
def change
create_table :posts do |t|
t.references :user, index: true
end
add_foreign_key :posts, :users
end
to
def change
create_table :posts do |t|
t.references :user, index: true, foreign_key: true
end
end
Changes `rails g migration add_user_to_posts user:references` from
def change
add_reference :posts, :users, index: true
add_foreign_key :posts, :users
end
to
def change
add_reference :posts, :users, index: true, foreign_key: true
end
|
|
|
|
|
|
|
|
|
|
|
| |
If you run a generator such as:
```
rails generate model accounts supplier:references
```
The resulting migration will now add the corresponding foreign key
constraint unless the reference was specified to be polymorphic.
|
|\
| |
| | |
Add a `required` option to the model generator
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Syntax was chosen to follow the passing of multiple options to
decimal/numeric types. Curly braces, and allowing any of `,`, `.`, or
`-` to be used as a separator to avoid the need for shell quoting. (I'm
intending to expand this to all columns, but that's another PR.
The `required` option will cause 2 things to change. `required: true`
will be added to the association. `null: false` will be added to the
column in the migration.
|
|/
|
|
|
|
|
| |
As per discussion, this changes the model generators to specify
`null: false` for timestamp columns. A warning is now emitted if
`timestamps` is called without a `null` option specified, so we can
safely change the behavior when no option is specified in Rails 5.
|
|
|
|
|
|
|
|
|
|
|
|
| |
ActiveRecord::Base.pluralize_table_names = false.
Previously, generation a migration like this:
rails g migration add_column_name_to_user name
would not generating the correct table name.
Fixes #13426.
|
| |
|
| |
|
| |
|
|
|
|
| |
ActiveRecord::Generators::MigrationGenerator.next_migration_number
|
|
|
|
|
|
|
|
|
|
| |
* adds password_digest attribute to the migration
* adds has_secure_password to the model
* adds password and password_confirmation password_fields to _form.html
* omits password entirely from index.html and show.html
* adds password and password_confirmation to the controller
* adds unencrypted password and password_confirmation to the controller test
* adds encrypted password_digest to the fixture
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Sometimes you want to create a table without an associated model and
test, which is also not a join table. With this commit, you can now
do that.
Example:
rails g migration create_posts title:string
or
rails g migration CreatePosts title:string
This commit also moves the template the model generator uses for the
migration to the migration templates folder, as it seems a more
sensible place for it now that it is shared code.
|
| |
|
|
|
|
|
|
|
|
| |
They was extracted from a plugin.
See https://github.com/rails/rails-observers
[Rafael Mendonça França + Steve Klabnik]
|
| |
|
| |
|
|
|
|
| |
move validation to AR
|
|
|
|
|
| |
This functionality will be available from gem
`active_record-session_store` instead.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
by Active Support)
Selecting which key extensions to include in active_support/rails
made apparent the systematic usage of Object#in? in the code base.
After some discussion in
https://github.com/rails/rails/commit/5ea6b0df9a36d033f21b52049426257a4637028d
we decided to remove it and use plain Ruby, which seems enough
for this particular idiom.
In this commit the refactor has been made case by case. Sometimes
include? is the natural alternative, others a simple || is the
way you actually spell the condition in your head, others a case
statement seems more appropriate. I have chosen the one I liked
the most in each case.
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For instance, running
rails g migration CreateMediaJoinTable artists musics:uniq
will create a migration with
create_join_table :artists, :musics do |t|
# t.index [:artist_id, :music_id]
t.index [:music_id, :artist_id], unique: true
end
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
AddXXXToYYY/RemoveXXXFromYYY migrations are produced with references
statements, for instance
rails g migration AddReferencesToProducts user:references
supplier:references{polymorphic}
will generate the migration with:
add_reference :products, :user, index: true
add_reference :products, :supplier, polymorphic: true, index: true
|
| |
|
|
|
|
|
|
|
|
|
|
| |
For instance,
$ rails g model Product supplier:references{polymorphic}
generate model with `belongs_to :supplier, polymorphic: true` association and appropriate migration.
Also fix model_generator_test.rb#L196 and #L201
|
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
$ rails generate migration remove_foo_from_bars foo:string
This currently generates:
def up
remove_column :bars, :foo
end
Fix it:
def up
remove_column :bars, :foo
end
|
|
|
|
| |
@spastorino request
|
|\
| |
| | |
Remove blank line from generated migration
|