For example PG refers to https://www.ietf.org/rfc/rfc3339.txt when converting(Ref: https://www.postgresql.org/docs/current/datatype-datetime.html)
According to the ref there is no explicit mention of allowing sign before the parts, which reads as below:
Durations:
dur-second = 1*DIGIT "S"
dur-minute = 1*DIGIT "M" [dur-second]
dur-hour = 1*DIGIT "H" [dur-minute]
dur-time = "T" (dur-hour / dur-minute / dur-second)
dur-day = 1*DIGIT "D"
dur-week = 1*DIGIT "W"
dur-month = 1*DIGIT "M" [dur-day]
dur-year = 1*DIGIT "Y" [dur-month]
dur-date = (dur-day / dur-month / dur-year) [dur-time]
duration = "P" (dur-date / dur-time / dur-week)
We should not attempt to move sign forward in this case.
In the same way that requests may need to be excluded from forced SSL,
requests may also need to be excluded from the Host Authorization
checks. By providing this additional flexibility more applications
will be able to enable Host Authorization while excluding requests
that may not conform. For example, AWS Classic Load Balancers don't
provide a Host header and cannot be configured to send one. This means
that Host Authorization must be disabled to use the health check
provided by the load balancer. This change will allow an application
to exclude the health check requests from the Host Authorization
requirements.
I've modified the `ActionDispatch::HostAuthorization` middleware to
accept arguments in a similar way to `ActionDispatch::SSL`. The hosts
configuration setting still exists separately as does the
hosts_response_app but I've tried to group the Host Authorization
settings like the ssl_options. It may make sense to deprecate the
global hosts_response_app if it's only used as part of the Host
Authorization failure response. I've also updated the existing tests
as the method signature changed and added new tests to verify the
exclusion functionality.
Re: https://github.com/rails/rails/issues/37066#issuecomment-709403972
Puma (and some other multi-threaded application servers) may check the `Thread` list before and after forking to look for any threads that may have been running during a call to `fork`. Threads running during a `fork` can leave memory and resources open and potentially cause leaks or deadlocks.
However, the Reaper thread in ActiveRecord cannot orphan any resources or memory, and will be cleaned up after forking.
Setting this thread local variable allows Puma and other application servers to ignore this thread for the purpose of displaying warnings to users about threads present and running during `fork`.
Co-authored-by: Eugene Kenny <elkenny@gmail.com>
Now that we have implemented granular connection swapping in #40370
we need a new API that will allow connections to multiple databases. The
reason we need this API is it will prevent deep nesting in cases where
we know that we want 3 of our 5 databases to connect to reading and
leave the rest on writing.
With this API, instead of writing:
```ruby
AnimalsRecord.connected_to(role: :reading) do
MealsRecord.connected_to(role: :reading) do
Dog.first # read from animals replica
Dinner.first # read from meals replica
Person.first # read from primary writer
end
end
```
This API would allow you to write:
```ruby
ActiveRecord::Base.connected_to_many([AnimalsRecord, MealsRecord], role: :reading) do
Dog.first # read from animals replica
Dinner.first # read from meals replica
Person.first # read from primary writer
end
```
This would come in especially handy for deeper nesting past 2 databases.
Co-authored-by: John Crepezzi <john.crepezzi@gmail.com>
- This is similar to other railties blocks (such as `console`,
`tasks` ...). The goal of this block is to allow the application
or a railtie to load code after the server start.
The use case can be to fire the webpack or react server in
development or start some job worker like sidekiq or resque.
Right now, all these tasks needs to be done in a separate
shell and gem maintainer needs to add documentation on
how to run their libraries if another program needs to run
next to the Rails server.
This feature can be used like this:
```ruby
class SuperRailtie < Rails::Railtie
server do
WebpackServer.run
end
end
```
Originally strict loading violations would always raise an error if
turned on for an association. This change allows for an application to
optionally log instead of raise. The behavior here is similar to how
strong parameters work. By default all environments will raise. An
application may want to use log in production while working on finding
all lazily loaded associations.
Set `config.active_record.action_on_strict_loading_violation` to `:log`
in your application to log instead of raise.
Follow-up to #34218.
This removes some filters that could filter innocuous fields such as
`author_name`. Filtering such fields might be surprising, especially to
people generating their first Rails app.
This commit also changes the `:password` filter to `:passw` so that it
can also filter fields such as `passwd`.
Reorders the methods since we usually go role, shard, then prevent
writes. I think it makes it easier to read.
Added documention to the methods for `current_shard` and
`current_preventing_writes`. These were originally marked as `nodoc` but
that doesn't make sense, apps may need to call these so we should make
them public.
When wrapping parameters, `_extract_parameters` is called twice for
every request. In most cases, both the `include` and `exclude` options
will be empty. In that case, we can use a logical check to save
allocation of an empty array and another allocation of a new array
concatenating the empty array with the hard-coded `EXCLUDE_PARAMETERS`.
The result is 4 array allocations less per request when wrapping is
enabled and `exclude` is not set.
Since 1944a7e74c, adding a foreign key or
check constraint to a non-existent table results in an unhelpful error:
NoMethodError: undefined method `scan' for nil:NilClass
This restores the previous behaviour of raising the underlying error
from the database, which describes the actual problem.
Rafael Mendonça França