In #23179 the migration generator was changed to no longer output `index: true` for `references` migrations. This updates the migrations guide to remove `index: true` from relevant examples.
[ci skip]
Check for any non-UTF8 characters in path parameters at the point they're
set in `env`. Previously they were checked for when used to get a controller
class, but this meant routes that went directly to a Rack app, or skipped
controller instantiation for some other reason, had to defend against
non-UTF8 characters themselves.
The `ActionDispatch::Static` middleware is used low down in the stack to serve
static assets before doing much processing. Since it's called from so low in
the stack, we don't have access to the request ID at this point, and generally
won't have any exception handling defined (by default `ShowExceptions` is added
to the stack quite a bit higher and relies on logging and request ID).
Before 8f27d6036a
this middleware would ignore unknown HTTP methods, and an exception about these
would be raised higher in the stack. After that commit, however, that exception
will be raised here.
If we want to keep `ActionDispatch::Static` so low in the stack (I think we do)
we should suppress the `ActionController::UnknownHttpMethod` exception here,
and instead let it be raised higher up the stack, once we've had a chance to
define exception handling behaviour.
This PR updates `ActionDispatch::Static` so it passes `Rack::Request` objects to
`ActionDispatch::FileHandler`, which won't raise an
`ActionController::UnknownHttpMethod` error. If an unknown method is
passed, it should exception higher in the stack instead, once we've had a
chance to define exception handling behaviour.`
The most complete list of field types appears in the `SchemaStatements` docs rather than the `TableDefinition` docs.
The change to link to `SchemaStatements` means that the explanation for the `index` parameter is no longer available on the linked-to page. A brief explanation of the `index` parameter is added directly in the guide to make up for this.
loaded model classes have their connections wrapped in transactions.
See #17776
In Rails 4 config.eager_load was changed to false in the test environment. This
means that model classes that connect to alternate databases with
establish_connection are not loaded at start up. If use_transactional_fixtures
is enabled, transactions are wrapped around the connections that have been
established only at the start of the test suite. So model classes loaded later
don't have transactions causing data created in the alternate database not to
be removed.
This change resolves that by creating a new connection.active_record
notification that gets fired whenever a connection is established. I then added
a subscriber after we set up transactions in the test environment to listen for
additional connections and wrap those in transactions as well.
