Recently started learning Rails through The Odin Project, and section 8.3 of the getting started guide is told to be avoided in the curriculum due to its confusing wording.
I moved the migration generation to the beginning of the section and changed the words 'you might add' to 'you would add'.
It might seem inconsequential but it hung myself and others at the TOP.
If there is a problem with my correction that I can fix, I will gladly do so.
By default, foreign key constraints in PostgreSQL are checked after each statement. This works for most use cases, but becomes a major limitation when creating related records before the parent record is inserted into the database.
One example of this is looking up / creating a person via one or more unique alias.
```ruby
Person.transaction do
alias = Alias
.create_with(user_id: SecureRandom.uuid)
.create_or_find_by(name: "DHH")
person = Person
.create_with(name: "David Heinemeier Hansson")
.create_or_find_by(id: alias.user_id)
end
```
Using the default behavior, the transaction would fail when executing the first `INSERT` statement.
This pull request adds support for deferrable foreign key constraints by adding a new option to the `add_foreign_key` statement in migrations:
```ruby
add_foreign_key :aliases, :person, deferrable: true
```
The `deferrable: true` leaves the default behavior, but allows manually deferring the checks using `SET CONSTRAINTS ALL DEFERRED` within a transaction. This will cause the foreign keys to be checked after the transaction.
It's also possible to adjust the default behavior from an immediate check (after the statement), to a deferred check (after the transaction).
```ruby
add_foreign_key :aliases, :person, deferrable: :deferred
```
The framework defaults file sets the serializer to `:hybrid` instead of
`:marshal`, but we can just remove the actual setting and referer to the
defaults file instead. [ci-skip]
We were planning to remove this middleware because we thought it could
make easier to attacker to do a Time Attack. However, while
Rack::Runtime can indeed be used to know how long a request took, and
compare with other requests, it doesn't provide any information that
can't be found in the total time of the request as well.
Instead of removing the middleware, we decided to keep it, and direct
users to instead of removing it, use its information to uncover actions
that are vulnerable to Time Attack.
This reverts commit 127dd06df66552dd272eea7832f8bb205cf6fd01, reversing
changes made to 4354e3ae492e95934a6da4101556a05d20b9f897.
Currently `ActiveModel::Model` is defined as the minimum API to talk
with Action Pack and Action View.
Its name suggests it can be included to create Active Record type
models, but for creating models it's probably too minimal. For example
it's very common to include ActiveModel::Attributes as well.
By moving `ActiveModel::Model`'s implementation to a new
`ActiveModel::API` we keep a definition of the minimum API to talk with
Action Pack and Action View.
For `ActiveModel::Model` we only need to include `ActiveModel::API`.
This will allow adding more funcationality to `ActiveModel::Model` while
keeping backwards compatibility.
Co-authored-by: Nathaniel Watts <1141717+thewatts@users.noreply.github.com>
* More succinct Gemfile comments
* Use double plings
* Separate gems with comments
* Correct separation at the top
* Style
* Use comments for all rails options
* Clearer still
* Clear invocation pointer
* Move tzinfo-data up to all the other gems that are available everywhere
* More succinct
* Better order and spacing
* Add similar read more link style
* No Sass recommendation on minimal
Fix the following error.
```
/Users/9sako6/.rbenv/versions/2.7.1/lib/ruby/gems/2.7.0/bundler/gems/rails-366c8f081d8b/actionpack/lib/action_dispatch/routing/mapper.rb:1865:in `map_match': undefined local variable or method `on' for #<ActionDispatch::Routing::Mapper:0x00007fd78a132bf8> (NameError)
```
