Rails 7 apps require running in `zeitwerk` mode, so we no longer need
the migration guide. The "Autoloading and Reloading Constants" guide
also handles autoloading with Zeitwerk, including `autoload_paths`, the
`zeitwerk:check` command and more.
- [x] We talk about transactions and how to disable them early on, as part of the first few paragraphs, that could be a subsection to add separation.
- [x] The guide goes into reversible early, before even talking about generating migrations and other basic stuff, and then later talks more about it. I think it's important to lay the foundation of change vs up/down, and the fact that migrations should always try to be able to be rolled back, but maybe we can do that without going into reversible that early in the guide, which complicates things further.
- [x] We mention bin/rails generate --help to look for more details, but we could mention specific generators also offer help too, e.g. bin/rails generate model --help or bin/rails generate migration --help
- [x] There's a small section about composite PKs, but there's also [a whole guide on it](https://edgeguides.rubyonrails.org/active_record_composite_primary_keys.html), we can add a link to it from the migrations guide at least for more info on the topic.
- [x] The section that talks about execute shows an example of a specific model Product.connection.execute, but we can call execute directly within a migration, that might be simpler to show.
- [x] We talk about "seed data " in setup & preparing sections, but never mention it before, or explain what seed data is. There's a section about seed data later in the guide, perhaps we can link to it to facilitate.
- [x] In "running specific migrations", bin/rails db:migrate VERSION=zomg actually raises a different error: Invalid format of target version: `VERSION=zomg`... might need a different example there for the unknown migration version error. (no need to show this invalid format one)
- [x] The section about referential integrity can likely be better explained, in particular I think it's worth mentioning that even though the "AR method/way" (the pattern, I mean) doesn't think such "intelligence" belongs to the database, foreign keys and unique indexes are generally safer at the database level. (and should likely have their counterparts explicitly added in code with associations and validations). I just don't want to convey that someone shouldn't be adding FKs & unique constraints, because not adding these can definitely bite you.
Other changes:
- [x] Moved sections around
- [x] Added a section about "Rails Migration Version Control"
- [x] Added a section about "Using UUIDs instead of IDs for Primary Keys"
Co-authored-by: bhumi1102 <bhumi1102@gmail.com>
Co-authored-by: Bartosz Łęcki <bart.lecki@gmail.com>
Co-authored-by: Cecile Veneziani <cveneziani@users.noreply.github.com>
Co-authored-by: hatsu <hajiwata0308@gmail.com>
Co-authored-by: Petrik de Heus <petrik@deheus.net>
Co-authored-by: Ahmad hamza <ahmad.hamza@toptal.com>
Co-authored-by: Bart de Water <496367+bdewater@users.noreply.github.com>
Co-authored-by: Amanda Perino <58528404+AmandaPerino@users.noreply.github.com>
Co-authored-by: Andy Atkinson <andyatkinson@gmail.com>
Co-authored-by: Jamie Gaskins <jgaskins@gmail.com>
Currently, there is no (simple) way to ask a model if it connects to a
single database or to multiple shards. Furthermore, without looping
through a model's connections, I don't believe there's an easy way to
return a list of shards a model can connect to.
This commit adds a `@shard_keys` ivar that's set whenever `.connects_to`
is called. It sets the ivar to the result of `shards.keys`. `shards` in
`.connects_to` defaults to an empty hash and therefore when calling
`connects_to database: {...}` `@shard_keys` will be set to an empty array.
`@shard_keys` is set _before_ the following lines:
```
if shards.empty?
shards[:default] = database
end
```
This conditional sets the one and only shard (`:default`) to the value of `database`
that we pass to `.connects_to`. This allows for calling
`connected_to(shard: :default)` on models configured to only connect to
a database e.g.:
```ruby
class UnshardedBase < ActiveRecord::Base
self.abstract_class = true
connects_to database: { writing: :primary }
end
class UnshardedModel < UnshardedBase
end
UnshardedBase.connected_to(shard: :default) {
UnshardedBase.connection_pool.db_config.name } => primary
```
This is ultimately still an _unsharded_ model which is why `@shard_keys`
gets set before the conditional.
With the new `@shard_keys` ivar we need a way for descendants of the
abstract AR model to return that same value. For that we leverage the
existing `.connection_class_for_self` method. That method returns the
ancestor of the model where `.connects_to` was called, or returns self if
it's the connection class:
```ruby
class UnshardedBase < ActiveRecord::Base
self.abstract_class = true
connects_to database: { writing: :primary }
end
class UnshardedModel < UnshardedBase
end
ActiveRecord::Base.connection_class_for_self => ActiveRecord::Base
UnshardedBase.connection_class_for_self => UnshardedBase(abstract)
UnshardedModel.connection_class_for_self => UnshardedBase(abstract)
```
The new `.shard_keys` method is a getter which returns the value of
`@shard_keys` from the connection class or it returns an empty array.
The empty array is necessary in cases where `connects_to` was never
called.
Finally, I've added an `.connected_to_all_shards` method which takes all of the
arguments for `.connected_to` except for `shard`. Instead, it loops through
every shard key and then delegates everything else to `.connected_to`. I've
used `.map` instead of `.each` so that we can collect the results of each block.
Fix#51284
Both Proxy controllers in Active Storage set the caching headers early
before streaming.
In some instances (see #51284), it is possible for the file
download (from the service to server) to fail before we send the first
byte to the client (response not yet committed).
In those instances, this change would invalidate the cache and return
a better response status before closing the stream.
Follow up to [#50527][]
Highlight the presence of the `yield :head` pattern established by
`turbo-rails` and adopted by Rails as part of [#50527][].
New applications will generate their application layout with `yield
:head`, so mention that in the documentation.
Also include the `yield :head` call in generated plugin layouts.
[#50527]: https://github.com/rails/rails/pull/50527
This commit addresses this CI failure:
https://buildkite.com/rails/rails/builds/108372#0190131e-ee1a-420b-8355-9eb08eb5c29a
* Without this commit
```ruby
$ ruby -v
ruby 3.2.4 (2024-04-23 revision af471c0e01) [x86_64-linux]
$ cd guides/bug_report_templates
$ ruby action_controller.rb
... snip ...
Installing rails 7.1.3.4
/home/yahonda/.rbenv/versions/3.2.4/lib/ruby/gems/3.2.0/gems/bundler-2.5.4/lib/bundler/runtime.rb:304:in `check_for_activated_spec!': You have already activated stringio 3.1.0, but your Gemfile requires stringio 3.1.1. Prepending `bundle exec` to your command may solve this. (Gem::LoadError)
from /home/yahonda/.rbenv/versions/3.2.4/lib/ruby/gems/3.2.0/gems/bundler-2.5.4/lib/bundler/runtime.rb:25:in `block in setup'
from /home/yahonda/.rbenv/versions/3.2.4/lib/ruby/gems/3.2.0/gems/bundler-2.5.4/lib/bundler/spec_set.rb:191:in `each'
from /home/yahonda/.rbenv/versions/3.2.4/lib/ruby/gems/3.2.0/gems/bundler-2.5.4/lib/bundler/spec_set.rb:191:in `each'
from /home/yahonda/.rbenv/versions/3.2.4/lib/ruby/gems/3.2.0/gems/bundler-2.5.4/lib/bundler/runtime.rb:24:in `map'
from /home/yahonda/.rbenv/versions/3.2.4/lib/ruby/gems/3.2.0/gems/bundler-2.5.4/lib/bundler/runtime.rb:24:in `setup'
from /home/yahonda/.rbenv/versions/3.2.4/lib/ruby/gems/3.2.0/gems/bundler-2.5.4/lib/bundler/inline.rb:66:in `block (2 levels) in gemfile'
from /home/yahonda/.rbenv/versions/3.2.4/lib/ruby/gems/3.2.0/gems/bundler-2.5.4/lib/bundler/settings.rb:158:in `temporary'
from /home/yahonda/.rbenv/versions/3.2.4/lib/ruby/gems/3.2.0/gems/bundler-2.5.4/lib/bundler/inline.rb:51:in `block in gemfile'
from /home/yahonda/.rbenv/versions/3.2.4/lib/ruby/gems/3.2.0/gems/bundler-2.5.4/lib/bundler.rb:403:in `block in with_unbundled_env'
from /home/yahonda/.rbenv/versions/3.2.4/lib/ruby/gems/3.2.0/gems/bundler-2.5.4/lib/bundler.rb:658:in `with_env'
from /home/yahonda/.rbenv/versions/3.2.4/lib/ruby/gems/3.2.0/gems/bundler-2.5.4/lib/bundler.rb:403:in `with_unbundled_env'
from /home/yahonda/.rbenv/versions/3.2.4/lib/ruby/gems/3.2.0/gems/bundler-2.5.4/lib/bundler/inline.rb:42:in `gemfile'
from action_controller.rb:5:in `<main>'
$
```
We're more likely to already have utc and can avoid constructing the
extra time object, and this will avoid deprecations on unconfigured
to_time_preserves_timezone.
Fix: #52111
Fix: 5dbc7b4
The above commit caused the size of the `CodeGenerator` method cache
to explode, because the dynamic namespace is way too granular.
But there is actually a much better fix for that, since `alias_attribute`
is now generating exactly the same code as the attribute it's aliasing,
we can generated it as the canonical method in the cache, and then just
define it in the model as the aliased name.
This prevent the cache from growing a lot, and even reduce memory
usage further as the original attribute and its alias now share
the same method cache.
Based on https://github.com/rails/rails/pull/52017
One concern raised by Xavier is users holding on the return value
of `.current_transaction` beyond the point where it is committed /
rolled back / invalidated.
I believe this is an invalid use of the API, just like holding
`ActiveRecord::Base.connection` beyond the scope of a request is.
However we can be more explicit about it, so I changed the callback
registration methods to raise an error when called on a finalized
transaction.
Another concern was the usability of the null-object in the Active
Record notification payloads, and I agree that while the null-object
make sense when calling `Model.current_transaction`, it doesn't make
sense to include it in the payload of events. The goal of the
`.current_transaction` API is to allow implementing transaction aware
code in a streamlined way. The goal of the `:transaction` in events
however it to allow logging whether a query was inside a transaction
or not, so it's much more ergonomic for it to be nilable.
So I kept Matthew's change that passes `transaction: nil` in `sql.active_record` events
when not inside a transaction. I also added test coverage to make
sure it behaves consistently whether we're inside a transactional
test or not.
I also kept the separation between internal and "user" transaction
objects, as I think it's a nice way to limit the effectively exposed
API, and prevent users from abusing that API too much.
Co-Authored-By: Jean Boussier <jean.boussier@gmail.com>
Currently, `ENV["SELENIUM_HOST"]` is evaluated when generating a file. So
the result was the following.
```
driven_by :selenium, using: :headless_chrome, screen_size: [ 1400, 1400 ], options: {
browser: :remote,
url: "http://:4444"
}
```
This PR fixes to output the URL setting just as a string. The after
result is the following.
```
driven_by :selenium, using: :headless_chrome, screen_size: [ 1400, 1400 ], options: {
browser: :remote,
url: "http://#{ENV["SELENIUM_HOST"]}:4444"
}
```
