The deprecation cycle can be confusing to contributors. We can add it to
the guide to help contributors.
Inspired by: b4fffc3c68 which already added some great
documentation.
Co-authored-by: Adrianna Chang <adrianna.chang@shopify.com>
I deprecated `legacy_connection_handling` setter in 7.0 but then removed
it without setting it to false by default upgraded apps might have this
set to false in their config and still be getting an error. This
confusing behavior came up with one of our apps at work.
To make it less confusing I've redefined `legacy_connection_handling`
setter and am raising an argument error if called. I didn't redefine the
getter because that shouldn't be in a config, it's not useful in that
context.
When working in a large rails app, I noticed in a flamegraph of a particular request that ~68ms was spent in the `xml_name_escape` method. I also ran an allocation tracer, which showed this method at the top of the list for String allocations.
This patch updates this method to avoid 3 String allocations:
- 2 allocations saved by using gsub! instead of gsub
- 1 allocation saved by concatenating to an existing string instead of allocating a new output string
For a rough benchmark in our rails app, I wrote a test with an allocation tracer around rendering a small view component.
- 244 String allocations before this change
- 228 String allocations from switching to gsub!
- 220 String allocations with this full patch
A ~10% reduction in String allocations in a real-world example seemed like a good justification for this small change.
When passing `nil` to `in_order_of`, the invalid SQL query is generated (because `NULL != NULL`):
```ruby
Book.in_order_of(:format, ["hardcover", "ebook", nil]).to_sql
```
```sql
SELECT "books".* FROM "books" WHERE "books"."format" IN ('hardcover', 'ebook', NULL)
ORDER BY CASE "books"."format" WHEN 'hardcover' THEN 1
WHEN 'ebook' THEN 2 WHEN NULL THEN 3 ELSE 4 END ASC
```
This PR also removes the special order field generation (`ORDER BY FIELD`) for MYSQL, because it is
unable to work with `NULL`s and the default `ORDER BY CASE` works for it (tested on MariaDB and MySQL 5.7+).
The various LogSubscriber subclasses tend to subscribe to events
but then end up doing nothing if the log level is high enough.
But even if we end up not logging, we have to go through the
entire notification path, record timing etc.
By allowing subscribers to dynamically bail out early, we can
save a lot of work if all subscribers are silenced.
This commit does two things.
1. Reverts a recent change that was calling SET DEFAULT NULL
when altering a table. This PR revert that back to instead call DROP
DEFAULT in the case when the column is not nullable.
2. Adds a check to ensure that only nonbinary data types are eligible
for having the `collation` carry through when performing a change_column
migration.
This moves some of the documentation from the `ErrorReporter` class
directly to the `handle` and `record` methods, and fleshes those out.
This also tweaks the documentation of the other `ErrorReporter` methods.
A recent change made it so that when you perform a change column
it will preserve collation on the column rather than nil it out·
which would select the database default. This works fine except in
the case of a binary type. In this case the collation should be
set to nil in the options so that the database default collation
type can be used on the column.
* This is an attempt to make the assert_enqueued_email_with easier to implement.
* Update actionmailer/test/test_helper_test.rb
Fix spelling.
* Documenting additional tests
* Missing a closing "end"
* Renaming tests for consistency
* Updating name
* Naming and documentation
* Leaving original test unchanged
* Fix test name, add new test
* Add assert_enqueued_emails examples to Rails guide
* Add example to test_helper
* Tweaking the Rails guide (#3)
* Updating Rails guide for consistency.
Co-authored-by: Bry <bryan.hunt@hey.com>
Co-authored-by: Ron Shinall <81988008+ron-shinall@users.noreply.github.com>
We'll ensure that any consumers that require ddl obtain it by visiting
the schema definition. Consequently, we should also stop visiting the
schema definition in the "schema definition builder" methods -- callers
will need to both build a schema definition, and then visit it using a
SchemaCreation object. This means schema definitions will not be populated
with SQL type information, or any other information that is set when
the definition is visited.