kotovalexarian-likes-github/rails--rails
1
0
Fork 0
mirror of https://github.com/rails/rails.git synced 2022-11-09 12:12:34 -05:00
Code Releases Activity

use bin/rails default instead of rake commands [ci skip]

Browse source 
I go through the `http://edgeguides.rubyonrails.org/` and found `rake` commands in various files that are in RAILS 5.0 implement by `bin/rails` command. I try to change all that can be directly use `bin/rails …`
This commit is contained in:
Gaurav Sharma 2016-01-19 16:38:56 +05:30
parent 3af3c19fd0
commit 352a8892fd
6 changed files with 37 additions and 37 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

14
guides/source/active_record_migrations.md
View file

@ -12,7 +12,7 @@ After reading this guide, you will know:
* The generators you can use to create them.
* The methods Active Record provides to manipulate your database.
* The Rake tasks that manipulate migrations and your schema.
* The bin/rails tasks that manipulate migrations and your schema.
* How migrations relate to `schema.rb`.
--------------------------------------------------------------------------------
@ -717,9 +717,9 @@ you will have to use `structure.sql` as dump method. See
Running Migrations
------------------
Rails provides a set of Rake tasks to run certain sets of migrations.
Rails provides a set of bin/rails tasks to run certain sets of migrations.
The very first migration related Rake task you will use will probably be
The very first migration related bin/rails task you will use will probably be
`rails db:migrate`. In its most basic form it just runs the `change` or `up`
method for all the migrations that have not yet been run. If there are
no such migrations, it exits. It will run these migrations in order based
@ -772,7 +772,7 @@ if you need to go more than one version back, for example:
$ bin/rails db:migrate:redo STEP=3
```
Neither of these Rake tasks do anything you could not do with `db:migrate`. They
Neither of these bin/rails tasks do anything you could not do with `db:migrate`. They
are simply more convenient, since you do not need to explicitly specify the
version to migrate to.
@ -784,7 +784,7 @@ it with the seed data.
### Resetting the Database
The `rails db:reset` task will drop the database and set it up again. This is
functionally equivalent to `rake db:drop db:setup`.
functionally equivalent to `rails db:drop db:setup`.
NOTE: This is not the same as running all the migrations. It will only use the
contents of the current `db/schema.rb` or `db/structure.sql` file. If a migration can't be rolled back,
@ -809,7 +809,7 @@ Active Record believes that it has already been run.
### Running Migrations in Different Environments
By default running `rake db:migrate` will run in the `development` environment.
By default running `bin/rails db:migrate` will run in the `development` environment.
To run migrations against another environment you can specify it using the
`RAILS_ENV` environment variable while running the command. For example to run
migrations against the `test` environment you could run:
@ -886,7 +886,7 @@ Occasionally you will make a mistake when writing a migration. If you have
already run the migration then you cannot just edit the migration and run the
migration again: Rails thinks it has already run the migration and so will do
nothing when you run `rails db:migrate`. You must rollback the migration (for
example with `rake db:rollback`), edit your migration and then run
example with `bin/rails db:rollback`), edit your migration and then run
`rails db:migrate` to run the corrected version.
In general, editing existing migrations is not a good idea. You will be

22
guides/source/engines.md
View file

@ -423,7 +423,7 @@ Finally, the assets for this resource are generated in two files:
`app/assets/stylesheets/blorgh/articles.css`. You'll see how to use these a little
later.
You can see what the engine has so far by running `rake db:migrate` at the root
You can see what the engine has so far by running `bin/rails db:migrate` at the root
of our engine to run the migration generated by the scaffold generator, and then
running `rails server` in `test/dummy`. When you open
`http://localhost:3000/blorgh/articles` you will see the default scaffold that has
@ -485,7 +485,7 @@ called `Blorgh::Comment`. Now run the migration to create our blorgh_comments
table:
```bash
$ rake db:migrate
$ bin/rails db:migrate
```
To show the comments on an article, edit `app/views/blorgh/articles/show.html.erb` and
@ -694,14 +694,14 @@ engine's models can query them correctly. To copy these migrations into the
application run the following command from the `test/dummy` directory of your Rails engine:
```bash
$ rake blorgh:install:migrations
$ bin/rails blorgh:install:migrations
```
If you have multiple engines that need migrations copied over, use
`railties:install:migrations` instead:
```bash
$ rake railties:install:migrations
$ bin/rails railties:install:migrations
```
This command, when run for the first time, will copy over all the migrations
@ -719,7 +719,7 @@ timestamp (`[timestamp_2]`) will be the current time plus a second. The reason
for this is so that the migrations for the engine are run after any existing
migrations in the application.
To run these migrations within the context of the application, simply run `rake
To run these migrations within the context of the application, simply run `bin/rails
db:migrate`. When accessing the engine through `http://localhost:3000/blog`, the
articles will be empty. This is because the table created inside the application is
different from the one created within the engine. Go ahead, play around with the
@ -730,14 +730,14 @@ If you would like to run migrations only from one engine, you can do it by
specifying `SCOPE`:
```bash
rake db:migrate SCOPE=blorgh
bin/rails db:migrate SCOPE=blorgh
```
This may be useful if you want to revert engine's migrations before removing it.
To revert all migrations from blorgh engine you can run code such as:
```bash
rake db:migrate SCOPE=blorgh VERSION=0
bin/rails db:migrate SCOPE=blorgh VERSION=0
```
### Using a Class Provided by the Application
@ -764,7 +764,7 @@ application:
rails g model user name:string
```
The `rake db:migrate` command needs to be run here to ensure that our
The `bin/rails db:migrate` command needs to be run here to ensure that our
application has the `users` table for future use.
Also, to keep it simple, the articles form will have a new text field called
@ -836,7 +836,7 @@ This migration will need to be run on the application. To do that, it must first
be copied using this command:
```bash
$ rake blorgh:install:migrations
$ bin/rails blorgh:install:migrations
```
Notice that only _one_ migration was copied over here. This is because the first
@ -851,7 +851,7 @@ Copied migration [timestamp]_add_author_id_to_blorgh_articles.blorgh.rb from blo
Run the migration using:
```bash
$ rake db:migrate
$ bin/rails db:migrate
```
Now with all the pieces in place, an action will take place that will associate
@ -1354,7 +1354,7 @@ need to require `admin.css` or `admin.js`. Only the gem's admin layout needs
these assets. It doesn't make sense for the host app to include
`"blorgh/admin.css"` in its stylesheets. In this situation, you should
explicitly define these assets for precompilation. This tells sprockets to add
your engine assets when `rake assets:precompile` is triggered.
your engine assets when `bin/rails assets:precompile` is triggered.
You can define assets for precompilation in `engine.rb`:

24
guides/source/getting_started.md
View file

@ -300,7 +300,7 @@ Rails.application.routes.draw do
# The priority is based upon order of creation:
# first created -> highest priority.
# See how all your routes lay out with "rake routes".
# See how all your routes lay out with "bin/rails routes".
#
# You can have the root of your site routed with "root"
# root 'welcome#index'
@ -359,13 +359,13 @@ Rails.application.routes.draw do
end
```
If you run `bin/rake routes`, you'll see that it has defined routes for all the
If you run `bin/rails routes`, you'll see that it has defined routes for all the
standard RESTful actions. The meaning of the prefix column (and other columns)
will be seen later, but for now notice that Rails has inferred the
singular form `article` and makes meaningful use of the distinction.
```bash
$ bin/rake routes
$ bin/rails routes
Prefix Verb URI Pattern Controller#Action
articles GET /articles(.:format) articles#index
POST /articles(.:format) articles#create
@ -559,10 +559,10 @@ this:
In this example, the `articles_path` helper is passed to the `:url` option.
To see what Rails will do with this, we look back at the output of
`bin/rake routes`:
`bin/rails routes`:
```bash
$ bin/rake routes
$ bin/rails routes
Prefix Verb URI Pattern Controller#Action
articles GET /articles(.:format) articles#index
POST /articles(.:format) articles#create
@ -702,10 +702,10 @@ two timestamp fields to allow Rails to track article creation and update times.
TIP: For more information about migrations, refer to [Rails Database Migrations]
(migrations.html).
At this point, you can use a rake command to run the migration:
At this point, you can use a bin/rails command to run the migration:
```bash
$ bin/rake db:migrate
$ bin/rails db:migrate
```
Rails will execute this migration command and tell you it created the Articles
@ -722,7 +722,7 @@ NOTE. Because you're working in the development environment by default, this
command will apply to the database defined in the `development` section of your
`config/database.yml` file. If you would like to execute migrations in another
environment, for instance in production, you must explicitly pass it when
invoking the command: `bin/rake db:migrate RAILS_ENV=production`.
invoking the command: `bin/rails db:migrate RAILS_ENV=production`.
### Saving data in the controller
@ -809,7 +809,7 @@ If you submit the form again now, Rails will complain about not finding the
`show` action. That's not very useful though, so let's add the `show` action
before proceeding.
As we have seen in the output of `bin/rake routes`, the route for `show` action is
As we have seen in the output of `bin/rails routes`, the route for `show` action is
as follows:
```
@ -871,7 +871,7 @@ Visit <http://localhost:3000/articles/new> and give it a try!
### Listing all articles
We still need a way to list all our articles, so let's do that.
The route for this as per output of `bin/rake routes` is:
The route for this as per output of `bin/rails routes` is:
```
articles GET /articles(.:format) articles#index
@ -1366,7 +1366,7 @@ Then do the same for the `app/views/articles/edit.html.erb` view:
We're now ready to cover the "D" part of CRUD, deleting articles from the
database. Following the REST convention, the route for
deleting articles as per output of `bin/rake routes` is:
deleting articles as per output of `bin/rails routes` is:
```ruby
DELETE /articles/:id(.:format) articles#destroy
@ -1562,7 +1562,7 @@ for it, and a foreign key constraint that points to the `id` column of the `arti
table. Go ahead and run the migration:
```bash
$ bin/rake db:migrate
$ bin/rails db:migrate
```
Rails is smart enough to only execute the migrations that have not already been

2
guides/source/plugins.md
View file

@ -247,7 +247,7 @@ and migrating the database. First, run:
```bash
$ cd test/dummy
$ bin/rake db:migrate
$ bin/rails db:migrate
```
While you are here, change the Hickwall and Wickwall models so that they know that they are supposed to act

8
guides/source/routing.md
View file

@ -1116,7 +1116,7 @@ Rails offers facilities for inspecting and testing your routes.
### Listing Existing Routes
To get a complete list of the available routes in your application, visit `http://localhost:3000/rails/info/routes` in your browser while your server is running in the **development** environment. You can also execute the `rake routes` command in your terminal to produce the same output.
To get a complete list of the available routes in your application, visit `http://localhost:3000/rails/info/routes` in your browser while your server is running in the **development** environment. You can also execute the `rails routes` command in your terminal to produce the same output.
Both methods will list all of your routes, in the same order that they appear in `config/routes.rb`. For each route, you'll see:
@ -1125,7 +1125,7 @@ Both methods will list all of your routes, in the same order that they appear in
* The URL pattern to match
* The routing parameters for the route
For example, here's a small section of the `rake routes` output for a RESTful route:
For example, here's a small section of the `rails routes` output for a RESTful route:
```
users GET /users(.:format) users#index
@ -1137,10 +1137,10 @@ edit_user GET /users/:id/edit(.:format) users#edit
You may restrict the listing to the routes that map to a particular controller setting the `CONTROLLER` environment variable:
```bash
$ CONTROLLER=users bin/rake routes
$ CONTROLLER=users bin/rails routes
```
TIP: You'll find that the output from `rake routes` is much more readable if you widen your terminal window until the output lines don't wrap.
TIP: You'll find that the output from `rails routes` is much more readable if you widen your terminal window until the output lines don't wrap.
### Testing Routes

4
guides/source/testing.md
View file

@ -399,11 +399,11 @@ structure. The test helper checks whether your test database has any pending
migrations. If so, it will try to load your `db/schema.rb` or `db/structure.sql`
into the test database. If migrations are still pending, an error will be
raised. Usually this indicates that your schema is not fully migrated. Running
the migrations against the development database (`bin/rake db:migrate`) will
the migrations against the development database (`bin/rails db:migrate`) will
bring the schema up to date.
NOTE: If existing migrations required modifications, the test database needs to
be rebuilt. This can be done by executing `bin/rake db:test:prepare`.
be rebuilt. This can be done by executing `bin/rails db:test:prepare`.
### The Low-Down on Fixtures