This week's Rails digest covers the new Agents on Rails announcement and its first LLM benchmark report, plus a batch of framework changes: support for the HTTP QUERY method in routing and request handling, a new Rails-flavored bin/console startup banner, configurable ffmpeg/ffprobe input arguments for Active Storage video previews, class-based variant processors, batched schema reader methods for multiple tables, a LengthValidator crash fix with proc minimums, bind parameters for array-form SQL arguments, deprecation of the create alias for insert, a new #kwargs accessor on middleware entries, ERB configuration moving to ActionView::Base, MySQL sql_mode now appending TRADITIONAL instead of STRICT_ALL_TABLES, pattern-based log filtering for ProxyLogger, new timezone mappings, a shape change to CommandRecorder#commands, and a fix ensuring normalizes runs before type validation.

4m read timeFrom rubyonrails.org
Post cover image

Questions this post answers

How do I use the new HTTP QUERY method in Rails routing?

Rails added native support for the HTTP QUERY method, a safe and idempotent method that carries the query in the request body rather than the URL, useful for large or structured queries. Define routes with the query method in routes.rb, check request.query? or request.request_method_symbol in controllers, and use the query helper in integration tests with params and an as: format. Developers adopting new Rails routing features can track framework changes like this on daily.dev.

Why does MySQL's sql_mode now append TRADITIONAL instead of STRICT_ALL_TABLES in Rails?

Rails changed its default MySQL adapter behavior to append TRADITIONAL rather than only STRICT_ALL_TABLES to sql_mode. On environments with an empty global sql_mode, such as default Amazon RDS and Aurora MySQL parameter groups, appending only STRICT_ALL_TABLES omitted NO_ZERO_IN_DATE, NO_ZERO_DATE, and ERROR_FOR_DIVISION_BY_ZERO, which MySQL 5.7+ otherwise enables by default; TRADITIONAL closes that gap. Teams running Rails on RDS or Aurora MySQL watch defaults like this on daily.dev to avoid silent behavior changes.

Why does my Active Record enum reject a value that should be normalized to a valid one?

A Rails bug caused the underlying type's assert_valid_value check to run against the raw, un-normalized value before normalizes had a chance to run, so a value like " Pending " would raise instead of becoming "pending" and passing enum validation. This has been fixed so normalization now runs first, letting normalized values pass validation as expected. Rails developers debugging enum and normalization interactions can follow fixes like this on daily.dev.

562 Impressions