{"id":15011,"date":"2026-11-02T07:00:00","date_gmt":"2026-11-02T13:00:00","guid":{"rendered":"https:\/\/www.allerin.com\/blog\/?p=15011"},"modified":"2026-10-31T07:32:17","modified_gmt":"2026-10-31T12:32:17","slug":"rails-preload-type-default-checks-30-october-2026","status":"publish","type":"post","link":"https:\/\/www.allerin.com\/blog\/rails-preload-type-default-checks-30-october-2026\/","title":{"rendered":"Rails preload, type and default checks, 30 October 2026"},"content":{"rendered":"
\n

On 2 November 2026, Rails 8.0 is five calendar days from the security-support deadline currently listed as 7 November<\/a>. The 30 October Rails weekly<\/a> offers useful regression checks for an upgrade: association scopes, text types, attribute defaults and generated HTML.<\/p>\n

These fixes are on pinned main<\/a>, absent from the checked released tags 8.1.4<\/a> and 8.0.5.1<\/a>. They are reasons to add tests before adopting a release containing them. A main merge does not establish the release that will carry a change.<\/p>\n

The comparisons below ran on 31 October with Ruby 3.4.10, released Rails 8.1.4 and that exact main commit. Database examples used disposable, in-memory SQLite databases. AI assistance was used to prepare and review these synthetic fixtures. They contain no client data and establish no production-upgrade result.<\/p>\n

A preload must preserve the association’s scope<\/h2>\n

PR #59444<\/a> addresses an association whose results depend on which other association was loaded first. When an unscoped has_many :through<\/code> association was preloaded before a scoped one sharing the same through association, Rails could reuse already loaded intermediate records and ignore the scoped association’s filtering condition.<\/p>\n

Preloading exists to avoid repeated association queries; it should preserve the records selected by the association. The reported example<\/a> was filed against development Rails in June. Our comparison checks released 8.1.4 as well, rather than assuming that the report’s version identifies the full affected range.<\/p>\n

On 8.1.4, loading all tags before inactive tags returned active tags in the inactive result. Reversing the order returned the correct identifiers. Main matched the ordinary association read in both orders, including active-only and empty controls.<\/p>\n

For an application using several scoped paths through one join model, compare the identifiers in both preload orders. A query-count assertion alone cannot detect the wrong records. Related fixes cover other through-preload conditions; this example does not establish every association shape’s behavior.<\/p>\n

Immutable strings should not erase a text type<\/h2>\n

The opt-in immutable_strings_by_default<\/code> setting arrived in Rails 6.1<\/a> after its merge in 2020. It lets applications that do not mutate returned strings avoid the duplication associated with mutation detection. It defaults to false; installing a newer Rails version does not by itself enable it.<\/p>\n

PR #59351<\/a> narrows that setting to actual string columns. Previously, types inheriting string behavior could also be converted. The upstream patch identifies text and several PostgreSQL types whose type information or specialized behavior could be lost.<\/p>\n

In our SQLite fixture, enabling the setting made a text column report :string<\/code> and return a frozen value on Rails 8.1.4. On main, it remained :text<\/code> and returned a mutable value. The ordinary string column remained frozen on both. Disabling the setting preserved the text type on both. These results cover SQLite string and text columns; the PostgreSQL consequences come from source review, not a PostgreSQL execution here.<\/p>\n

Inspect explicit uses of this setting and assert both the reported type and the mutation behavior the application expects. Do not enable it merely to obtain a new default, or infer that a successful value round trip proves that type-specific behavior survived.<\/p>\n

Check a declared default after reset<\/h2>\n

CurrentAttributes shipped in Rails 5.2 in 2018<\/a>. Its separate default:<\/code> option arrived in Rails 7.2 in 2024<\/a>. This week’s correction concerns attributes declared with string names.<\/p>\n

PR #59347<\/a> normalizes CurrentAttributes names to symbols when registering defaults. A string-named attribute could have a generated reader but a default stored under the wrong key.<\/p>\n

The synthetic declaration attribute \"region\", default: \"Europe\"<\/code> returned nil<\/code> on first access and after reset in Rails 8.1.4. Main returned \"Europe\"<\/code> in both cases. A symbol-named control worked on both, including restoration of a fresh mutable default after changing the previous value.<\/p>\n

For code declaring these attributes dynamically, test the initial read and the reset path. Explicitly assigning a value can hide the defect. This check concerns registration and reset of a synthetic value; it does not test request isolation or concurrency.<\/p>\n

Inspect the HTML that a helper emits<\/h2>\n

Rails 5.2’s tag helper<\/a>, released in 2018, already treated hidden<\/code> as a boolean attribute. That treatment persists in 8.1.4. PR #59340<\/a> preserves string and symbol values for hidden<\/code>, including until-found<\/code>.<\/p>\n

This complete example ran against both checked sources:<\/p>\n

require \"action_view\"\r\nhelper = Object.new.extend(ActionView::Helpers::TagHelper)\r\nputs helper.tag.div(hidden: \"until-found\")\r\n<\/code><\/pre>\n
Rails 8.1.4 emitted <div hidden=\"hidden\"><\/div><\/code>; main emitted <div hidden=\"until-found\"><\/div><\/code>. Boolean true still emitted hidden=\"hidden\"<\/code>, and false omitted the attribute, on both. The fixture verifies HTML serialization, not browser reveal behavior. If a view relies on the keyword, inspect its rendered attribute and test the intended interaction separately.<\/p>\n
What to carry into the upgrade<\/h2>\n