| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Adds an option to the migration generator to allow setting the
migrations paths for that migration. This is useful for applications
that use multiple databases and put migrations per database in their own
directories.
```
bin/rails g migration CreateHouses address:string --migrations-paths=db/kingston_migrate
invoke active_record
create db/kingston_migrate/20180830151055_create_houses.rb
```
|
| |
|
|
|
|
|
|
|
|
| |
Make clear that the files are not to be run for interpreters.
Fixes #23847.
Fixes #30690.
Closes #23878.
|
|
|
|
| |
And enable `context_dependent` of Style/BracesAroundHashParameters cop.
|
|
|
|
| |
Making sure the table name is parsed correctly when an add/remove column migration have 'from'/'to' in the table name.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When generating models, we created ApplicationRecord in the default
location if no file existed there. That was annoying for people who
moved it to somewhere else in the autoload path. At this point, the
vast majority of apps should have either run the upgrade script or
generated a model since upgrading. For those that haven't the error
message after generating a new model should be helpful:
NameError: uninitialized constant ApplicationRecord
To ease friction in that case, this also adds a generator for
ApplicationRecord.
|
| |
|
|
|
|
|
| |
This reverts commit 3420a14590c0e6915d8b6c242887f74adb4120f9, reversing
changes made to afb66a5a598ce4ac74ad84b125a5abf046dcf5aa.
|
| |
|
|
|
|
|
|
| |
".. with __dir__ we can restore order in the Universe." - by @fxn
Related to 5b8738c2df003a96f0e490c43559747618d10f5f
|
|
|
|
|
|
|
|
|
|
| |
In #27674 we changed the migration generator to generate migrations at
the path defined in `Rails.application.config.paths` however the code
checked for the presence of the `Rails` constant but not the
`Rails.application` method which caused problems when using Active
Record and generators outside of the context of a Rails application.
Fixes #28325.
|
|
|
|
|
| |
Since `Migration` module is included in both `MigrationGenerator` and
`ModelGenerator`, no need to define a common method for each class.
|
| |
|
|
|
|
| |
Actually, private methods cannot be called with `self.`, so it's not just redundant, it's a bad habit in Ruby
|
|
|
|
|
|
|
|
|
| |
mtsmfm/fix-generator-command-for-nested-rails-engine"
This reverts commit 1e969bfb98b88799e2c759fce25a1d8cf00d7ce7, reversing
changes made to a5041f267ded119c2d00b8786c2f2c1e3f93c8a1.
Reason: It breaks the public API
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
If we create nested (namespaced) rails engine such like bukkits-admin,
`bin/rails g scaffold User name:string age:integer`
will create
`bukkits-admin/app/controllers/bukkits/users_controller.rb`
but it should create
`bukkits-admin/app/controllers/bukkits/admin/users_controller.rb`.
In #6643, we changed `namespaced_path` as root path
because we supposed application_controller is always in root
but nested rails engine's application_controller will not.
|
|
|
|
|
|
| |
Follow up to 5b14129d8d4ad302b4e11df6bd5c7891b75f393c.
http://edgeapi.rubyonrails.org/classes/ActiveRecord/Attribute.html
|
| |
|
| |
|
|
|
|
|
|
| |
Regexp#match? should be considered to be part of the Ruby core library. We are
emulating it for < 2.4, but not having to require the extension is part of the
illusion of the emulation.
|
|
|
|
|
|
| |
All indentation was normalized by rubocop auto-correct at 80e66cc4d90bf8c15d1a5f6e3152e90147f00772.
But comments was still kept absolute position. This commit aligns
comments with method definitions for consistency.
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
| |
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
|