I was running into a case where I didn't want to just disabled the
validations and add my own. In fact, I would very much like to keep the
default validation but just de-activate it on some scenario:
e.g. Inviting a user without having to set a password for them yet so
they can add it themselves later when they receive an email invitation
to finish setting up their account.
My understanding of the validations flag originally intended was to
just disabled them and if you needed something more custom, you could
run your own validations instead.
This would be an acceptable solution, but it would add more code to my
controller. Instead validations can receive a `Hash` wich is then use to
apply validations rules to `validate`.
This is just a suggestion, I am not sure if there is a need, and I am
aware this PR is probably far from perfect. Any feedback welcome.
EDIT: implemented changes as per feedback.
The block can't affect reconnectability, because we'll be re-running it
anyway.
Also, only #reconnect! once per query, to avoid squaring the total
number of permitted retries while attempting to query a pathologically
flakey server.
Connectivity issues need a reconnect to be retried, but there are also
in-server errors that can also be retried (lock timeouts and deadlocks).
To handle this better, we move translation into #with_raw_connection:
it's a much better representation of the boundary between the underlying
adapter library and Active Record's abstractions anyway. (It doesn't
know about the query being run, though, so we let #log enrich that into
the exception later.)
We may be restoring a connection after #with_raw_connection has already
passed #materialize_transactions, so it's important we eagerly return
things to exactly the state they had before.
So far this is just infrastructure: no errors are considered retryable,
and no real queries are marked retryable.
Even in this state, we can drop connection verification from checkout,
and defer it until the first query is ready. But the more interesting
within-reach win will be when 'BEGIN' is retryable, and we can recognise
connectivity-related exceptions.
This pattern is useful in some cases, like moving the project folder
from myapp to myapp_moved, or testing generated behavior based on the
app name being hyphenated-app.
However, for the majority of cases this is not needed and adds
additional complexity to some assertion helpers. For example,
`assert_file` always expands paths relative to `destination_root`
instead of whatever the working directory is.
Prior to this commit, `EncryptedFile` would internally memoize when a
key file was non-existent. This meant that a key file generated after
checking `encrypted_file.key.nil?` would not be recognized, unless a new
`EncryptedFile` instance was used. (Though setting the key in a
designated environment variable instead would entirely bypass this
memoization.)
This commit changes `EncryptedFile` to only memoize when the key file
has been read. Consequently, this commit memoizes the `EncryptedFile`
(or, specifically, `EncryptedConfiguration`) instance used by
`CredentialsCommand`.
This commit also adds more test coverage around key file generation for
`CredentialsCommand`.
This commit addresses bug_report_templates/action_controller_gem.rb failures.
```
% ruby -v
ruby 3.1.2p20 (2022-04-12 revision 4491bb740a) [arm64-darwin22]
% cd guides/bug_report_templates
% ruby action_controller_gem.rb
Fetching gem metadata from https://rubygems.org/...........
... snip ...
Using rails 7.0.3.1
/Users/yahonda/.rbenv/versions/3.1.2/lib/ruby/gems/3.1.0/gems/bundler-2.3.14/lib/bundler/runtime.rb:309:in `check_for_activated_spec!': You have already activated strscan 3.0.2, but your Gemfile requires strscan 3.0.4. Prepending `bundle exec` to your command may solve this. (Gem::LoadError)
from /Users/yahonda/.rbenv/versions/3.1.2/lib/ruby/gems/3.1.0/gems/bundler-2.3.14/lib/bundler/runtime.rb:25:in `block in setup'
from /Users/yahonda/.rbenv/versions/3.1.2/lib/ruby/gems/3.1.0/gems/bundler-2.3.14/lib/bundler/spec_set.rb:138:in `each'
from /Users/yahonda/.rbenv/versions/3.1.2/lib/ruby/gems/3.1.0/gems/bundler-2.3.14/lib/bundler/spec_set.rb:138:in `each'
from /Users/yahonda/.rbenv/versions/3.1.2/lib/ruby/gems/3.1.0/gems/bundler-2.3.14/lib/bundler/runtime.rb:24:in `map'
from /Users/yahonda/.rbenv/versions/3.1.2/lib/ruby/gems/3.1.0/gems/bundler-2.3.14/lib/bundler/runtime.rb:24:in `setup'
from /Users/yahonda/.rbenv/versions/3.1.2/lib/ruby/gems/3.1.0/gems/bundler-2.3.14/lib/bundler/inline.rb:71:in `block in gemfile'
from /Users/yahonda/.rbenv/versions/3.1.2/lib/ruby/gems/3.1.0/gems/bundler-2.3.14/lib/bundler/settings.rb:131:in `temporary'
from /Users/yahonda/.rbenv/versions/3.1.2/lib/ruby/gems/3.1.0/gems/bundler-2.3.14/lib/bundler/inline.rb:55:in `gemfile'
from action_controller_gem.rb:5:in `<main>'
%
```
strscan 3.0.4 has been released on July 23, 2022.
https://rubygems.org/gems/strscan/versions/3.0.4
Refer to https://github.com/rails/rails/pull/45052 for the similar change.
https://github.com/rubygems/rubygems/pull/5529https://github.com/rubygems/rubygems/pull/5535
155b757 added some yarn commands to bin/setup for apps that are using
Node. However, the blank line between the added block and the
skip_active_record block results in an extraneous blank line added to
apps when running app:update.
Previously running app:update always would template an application.rb
file without the `config.generators.system_tests = nil` set, even for
applications that previously had it set.
We should not need to check defined? here because we are only interested
in whether @html_safe is truthy or falsy.
We can use an aliased attr_reader to make this even faster by skipping
both method dispatch.
Co-authored-by: Jean Boussier <jean.boussier@gmail.com>
Previously, BigDecimal was listed as not needing a serializer. However,
when used with an adapter storing the job arguments as JSON, it would get
serialized as a simple String, resulting in deserialization also producing
a String (instead of a BigDecimal).
By using a serializer, we ensure the round trip is safe.
During upgrade deployments of applications with multiple replicas making use of
BigDecimal job arguments with a queue adapter serializing to JSON, there exists
a possible race condition, whereby a "new" replica enqueues a job with an
argument serialized using `BigDecimalSerializer`, and an "old" replica fails to
deserialize it (as it does not have `BigDecimalSerializer`).
Therefore, to ensure safe upgrades, serialization will not use
`BigDecimalSerializer` until `config.active_job.use_big_decimal_serializer` is
enabled, which can be done safely after successful deployment of Rails 7.1.
This option will be removed in Rails 7.2, when it will become the default.
Define API on connection adapter for building a TableDefinition.
The provided TableDefinition object offers insight into what a table
created using the migration method #create_table would look like, including
information on primary keys, column types, etc.
As a part of this PR, we extract TableDefinition#set_primary_key to handle
some of the primary key setting logic currently being performed in #create_table.
The `_dump` task is private so it shouldn't be called by apps. Because
of this were establishing a connection to the db_config twice, once in
`_dump` and once in `dump`. There's no reason to do this since `_dump`
always calls `dump` and apps should not be calling `_dump`.
