Currently, the file generated via the generator is pluralized
but the parent class is singluar.
example: bundle exec rails g scaffold Pet name:string --database=animals
The above command should generate: apps/models/animals_record.rb
but the pets model would inherit from: `AnimalRecord` as
`"animals".classify` would be `Animal`
This will throw the `uninitialized constant AnimalRecord Did you mean? AnimalsRecord`
error.
For example, for a plugin like `my_plugin`, this makes the
`MyPlugin::VERSION` constant available to all consumers by default.
This commit also replaces the default generated test with a test that
the developer is less likely to delete.
On current master with multiple DBs configured, calling db:migrate:redo fails when trying to run db:rollback.
Before:
```
» bin/rails db:migrate:redo
rake aborted!
You're using a multiple database application. To use `db:rollback` you must run the namespaced task with a VERSION. Available tasks are db:rollback:primary and db:rollback:secondary.
Tasks: TOP => db:rollback
(See full trace by running task with --trace)
```
After:
```
» bin/rails db:migrate:redo
rake aborted!
You're using a multiple database application. To use `db:migrate:redo` you must run the namespaced task with a VERSION. Available tasks are db:migrate:redo:primary and db:migrate:redo:secondary.
Tasks: TOP => db:migrate:redo
(See full trace by running task with --trace)
```
Running the namespaced version:
```
» bin/rails db:migrate:redo:secondary
== 20200728162820 CreateAnimals: reverting ====================================
-- drop_table(:animals)
-> 0.0025s
== 20200728162820 CreateAnimals: reverted (0.0047s) ===========================
== 20200728162820 CreateAnimals: migrating ====================================
-- create_table(:animals)
-> 0.0028s
== 20200728162820 CreateAnimals: migrated (0.0029s) ===========================
```
This PR ensures that when you're generating a scaffold or model and that
model should belong to another database it will create an abstract class
if it doesn't already exist.
The new abstract class will ensure that the new model inherits from that
class, but will not be deleted if the scaffold is deleted. This is
because Rails can't know if you have other models inheriting from that
class so we don't want to revoke that if the scaffold is destroyed.
If the abstract class already exists it won't be created twice. If the
options for `parent` are set, the generator will use that as the
abstract class instead of creating one. The generated abstract class
will add the writing connection automatically, users need to add the
reading connection themselves as Rails doesn't know which is the reading
connection.
Co-authored-by: John Crepezzi <john.crepezzi@gmail.com>
The `config/application.rb` file of a plugin test dummy app should be
the same as in a standard Rails app, with the exception of an additional
`require` statement to load the plugin itself. However, prior to this
commit, the plugin generator used a specialized template for a portion
of this file, which tended to drift out-of-sync with the standard app
generator's template. Specifically, this drift could result in missing
`require` statements of newer Rails frameworks when the plugin generator
was run with any `--skip-xxxx` option.
This commit changes the plugin generator to insert its additional
`require` statement into the standard `config/application.rb` file
generated by the app generator.
Engines are not applications, indeed 'Application < Engine', so it's the other way round.
The difference can be confusing anyway, so we should make sure the documentation is clear.
308 status code introduced in https://tools.ietf.org/html/rfc7538
preserves the request method unlike 301 status code which would convert
POST requests to GET.
This change swaps the CommonJS require() syntax in the Webpacker
application.js pack template file and in documentation examples with ES
module import syntax.
Benefits of this change include:
Provides continuity with the larger frontend community: Arguably, one of
the main draws in adopting Webpacker is its integration with Babel to
support ES module syntax. For a fresh Rails install with Webpacker, the
application.js file will be the first impression most Rails developers
have with webpack and Webpacker. Most of the recent documentation and
examples they will find online for using other libraries will be based
on ES module syntax.
Reduces confusion: Developers commonly add ES imports to their
application.js pack, typically by following online examples, which means
mixing require() and import statements in a single file. This leads to
confusion and unnecessary friction about differences between require()
and import.
Embraces browser-friendliness: The ES module syntax forward-looking and
is meant to be supported in browsers. On the other hand, require()
syntax is synchronous by design and not browser-supported as CommonJS
originally was adopted in Node.js for server-side JavaScript. That
webpack supports require() syntax is merely a convenience.
Encourages best practices regarding optimization: webpack can statically
analyze ES modules and "tree-shake", i.e., strip out unused exports from
the final build (given certain conditions are met, including
`sideEffects: false` designation in package.json).
If an assertion is inside a method stub, it may never be evaluated.
This is particularly problematic when asserting a method is called a
non-zero number of times.
This commit moves such assertions outside their method stubs.
Follow up to c07dff72278fb7f2a3c4c71212a0773a2b25c790.
Actually it is not the cop's fault, but we mistakenly use `^`, `$`, and
`\Z` in much places, the cop doesn't correct those conservatively.
I've checked all those usage and replaced all safe ones.
Silence Rake task backtraces, similar to Rails::BacktraceCleaner.
Application lines are preserved, but all other lines are hidden.
This also affects unrecognized tasks, causing the backtrace to be hidden
entirely. Closes#39524.
Co-authored-by: Petrik <petrik@deheus.net>
This test was incorrect. `primary` was winning for the schema cache load
but when you boot an application it's actually the first configuration
that wins (in a multi db app).
The test didn't catch this because I forgot to add a migrations_paths to
the configuration.
We updated the schema cache loader railtie as well because any
application that didn't have a `primary` config would not be able to use
the schema cache. Originally we thought we'd enforce a `primary`
configuration but no longer feel that's correct. It's simpler to say
that the first wins in a 3-tier rather than implementing a solution to
require `primary` and / or allow aliases.
Co-authored-by: John Crepezzi <john.crepezzi@gmail.com>
Co-authored-by: John Hawthorn <john@hawthorn.email>
Applications may not have a primary configuration so we should not
assume there is one. In both these cases we can get the right connection
without that.
For the databases.rake file we want to re-establish a connection for the
environment we're in. The first config defined under an environment for
a multi-db app will win. This is already the case on application boot so
we should be consistent.
For the info.rb file we already have a connection so we can lookup the
adapter from the connection's db_config. If a primary hadn't existed
this would have thrown an exception.
Followup to https://github.com/rails/rails/pull/39535 which removed the
assumption there was a primary config from the schema cache load
railtie.
Co-authored-by: John Crepezzi <john.crepezzi@gmail.com>
Generators generate things, but what is meant by 'Stubbing out' might
confuse beginners and non-native English speakers.
While generated tests are stubs that should have an implementation, a
generated model is a valid model that doesn't require any changes.
