attribute` is back, pluck on unsaved records, and more!
This title could be clearer and more informative.Try out Clickbait Shieldfor free (5 uses left this month).
This week in Rails covers several bug fixes and improvements: `CollectionProxy#pluck` now reads in-memory records on unsaved associations; `alias_attribute` support is restored in associations after being broken since Rails 4.2; new query predicate hooks let Active Record types customize `where` predicate building; `search_field` with `autosave: true` no longer raises `NameError`; job continuation cursors now preserve their type across interrupts via `ActiveJob::Arguments`; prepared statements can now coexist with query log tags; SQL logs show positional markers for casted binds; Mime types and the Action View dependency tracker registry are made Ractor-shareable. Several internal APIs are deprecated, including `write_attribute(:id, value)`, positional `#insert` arguments, and passing raw binds to `#insert`, `#update`, and `#delete`. Matz is also announced as a speaker at Rails World 2026 in Austin.
Questions this post answers
Why does CollectionProxy#pluck return empty on a new unsaved record even when associations are assigned in Rails?
When the parent record is unsaved, `CollectionProxy#pluck` was reading the null scope instead of the in-memory records assigned to the association. A regression that made `ids` delegate to `pluck` caused both to return empty. The fix makes `pluck` read target records directly, so `post.tags.pluck(:name)` returns assigned tag names before the record is saved. Rails developers tracking association edge cases like this find the weekly changelog useful on daily.dev.
Why was alias_attribute on a foreign key silently ignored in Rails associations?
Since Rails 4.2, association reads used an internal fast path that bypassed `read_attribute`, skipping alias resolution entirely. This meant an `alias_attribute` on the owner's foreign key or the target's primary key was silently ignored. The performance gap between the fast path and the standard path has since closed, so associations now honor aliases again. Developers maintaining Rails apps with aliased foreign keys can track fixes like this on daily.dev.
How do I fix job continuation cursors losing their type (Date, Time) after an ActiveJob interrupt and resume?
Cursors were previously persisted as raw JSON, so a `Date`, `Time`, or GlobalID cursor was deserialized as a plain `String` after interrupt and resume, breaking methods like `cursor.beginning_of_day`. The fix serializes cursors through `ActiveJob::Arguments` — the same path used for job arguments — so the resumed step receives the same typed object that was set before interruption. Teams building reliable background job pipelines with Rails can follow serialization fixes like this on daily.dev.