To avoid accidental writing to the production database, I always start
rails console in sandbox mode. I only start rails console in non-sandbox
mode when I'm sure I want to write to the production database.
`sandbox_by_default` option is added to start rails console in sandbox
mode by default. With this option turned on, `--no-sandbox` must be
specified to start rails in non-sandbox mode.
Note that this option is ignored when rails environment is development
or test.
This allows access to the raw id column value on records for which an
id column exists but is not the primary key. This is common amongst
models with composite primary keys.
rails/rails@a88f47d fixed an issue where subclasses were regenerating aliased attribute methods defined on parent classes. Part of the solution was to call #generate_alias_attributes recursively on a class's superclass to generate all the alias attributes in the inheritance hierarchy. However, the implementation relies on #base_class to determine if we should call #generate_alias_attributes on the superclass. Since all models that inherit from abstract classes are base classes, this means that #generate_alias_attributes will never be called on abstract classes, meaning no method will be generated for any alias attributes defined on them.
To fix this issue, we should always call #generate_alias_attributes on the superclass unless the superclass is ActiveRecord::Base.
I'm working on an enhancement to query constraints that will require me
to know when we have query constraints but not a composite key.
Currently if you have a composite key it will be included in the query
constraints list. There's not a way to differentiate between the two
which means that we're forced into setting the query constraints on the
associations for the primary key.
This change adds a `has_query_constraints?` method so we can check the
class for query constraints. The options still work as well but we can
be sure we're always picking up the query constraints when they're
present.
This `#use_puma?` check was [introduced][1] because Rails could
potentially display the wrong server URL in development if another host
or port is configured in `config/puma.rb`.
However, in Rack 3 the the name of the server class changed from
`Rack::Handler::Puma` to `Rackup::Handler::Puma`, which means that the
served_url is being logged again.
This commit fixes the check to accept either version of the class.
Additionally, puma was updated in Gemfile.lock because Puma 6.0.x prints
a deprecation warning about Rack::Handler that's fixed in 6.1.0.
[1]: 29648ff60e66c674b3cc49151df15dc100ffb4f4
Follow-up to #47178.
RDoc's Markdown parser requires multi-line list items to use a hanging
indent of at least four spaces. Otherwise, trailing lines will be
rendered as an independent paragraph, and the next list item will start
a new list.
We originally implemented this project to use OR queries instead of IN
because it seemed like there was no way to do that without a row
constructor. While working on implementing this feature in our vitess
gem I noticed that we can actually get the queries we wanted, and the
new code is more performant than generating an OR.
SQL Before:
```sql
SELECT "sharded_comments".*
FROM "sharded_comments"
WHERE ("sharded_comments"."blog_id" = 969142904
AND ("sharded_comments"."blog_post_id" = 357271355
OR "sharded_comments"."blog_post_id" = 756811794)
OR "sharded_comments"."blog_id" = 308674288
AND "sharded_comments"."blog_post_id" = 1055755181)
```
SQL After:
```sql
SELECT "sharded_comments".*
FROM "sharded_comments"
WHERE "sharded_comments"."blog_id"
IN (969142904, 308674288)
AND "sharded_comments"."blog_post_id"
IN (357271355, 756811794, 1055755181)
```
Using one of the tests that utilizes this code path, I benchmarked the
queries. The new implementation is faster:
Before:
```
Warming up --------------------------------------
queries 147.000 i/100ms
Calculating -------------------------------------
queries 1.486k (± 3.2%) i/s - 7.497k in 5.050742s
```
After:
```
Warming up --------------------------------------
queries 179.000 i/100ms
Calculating -------------------------------------
queries 1.747k (± 4.5%) i/s - 8.771k in 5.031424s
```
We can probably improve this more but I think this query is more in line
with what we want and expect while also being more performant (without
having to build a new row constructor in arel).
