When an attribute is missing the current message is unclear about which
class is missing the attribute, especially when there are multiple
classes that could miss the attribute.
By adding the classs name to the error message it is easier to debug:
```ruby
user = User.first
user.pets.select(:id).first.user_id
=> ActiveModel::MissingAttributeError: missing attribute 'user_id' for Pet
```
This also makes the error message more inline with the
UnknownAttributeError message:
```ruby
=> ActiveModel::UnknownAttributeError: unknown attribute 'name' for Person
```
Co-authored-by: Yasuo Honda <yasuo.honda@gmail.com
Given a models setup like:
```ruby
class BlogPost < ApplicationRecord
query_constraints :blog_id, :id
has_many :comments, query_constraints: [:blog_id, :blog_post_id]
end
class Comment < ApplicationRecord
query_constraints :blog_id, :blog_post_id
belongs_to :blog_post, query_constraints: [:blog_id, :blog_post_id]
end
```
It should be possible to nullify both `blog_post.comments = []` and
`comment.blog_post = nil` association which should result in
nullification of all parts of the composite query constraints,
meaning `blog_id` and `blog_post_id` being nil on the affected comments.
Co-authored-by: Paarth Madan <paarth.madan@shopify.com>
`where_values_hash` method signature accepts `table_name` which is not
always the same as the association name.
So passing `through_association.reflection.name.to_s` as `table_name`
in `through_scope_attributes` wasn't accurate for every case.
This commit fixes the issue by passing the `table_name` taken from
`through_association.reflection.klass.table_name` instead.
Given a has_many through association with a composite foreign key, like:
```ruby
class BlogPost < ApplicationRecord
query_constraints :blog_id, :id
has_many :blog_post_tags, query_constraints: [:blog_id, :blog_post_id]
has_many :tags, through: :blog_post_tags
end
class BlogPostTag < ApplicationRecord
belongs_to :blog_post, query_constraints: [:blog_id, :blog_post_id]
belongs_to :tag, query_constraints: [:blog_id, :tag_id]
end
class Tag < ApplicationRecord
query_constraints :blog_id, :id
has_many :blog_post_tags, query_constraints: [:blog_id, :tag_id]
has_many :blog_posts, through: :blog_post_tags
end
```
It should be possible to assign tags to a blog post:
```ruby
blog_post = BlogPost.create!(title: "Hello world")
blog_post.tags << Tag.new(name: "ruby")
```
* Replace call to BINARY with CAST(_ AS BINARY)
* Remove space b/w function and quote
Co-authored-by: Rafael Mendonça França <rafael@franca.dev>
* Update unit test to assert for new CAST syntax
---------
Co-authored-by: Rafael Mendonça França <rafael@franca.dev>
Now that we support a way to register custom configurations we need to
allow applications to find those configurations. This change adds a
`config_key` option to `configs_for` to find db configs where the
configuration_hash contains a particular key.
I have also removed the deprecation for `include_replicas` while I was
in here to make the method signature cleaner. I've updated the upgrade
guide with the removal.
Previously, applications could only have two types of database
configuration objects, `HashConfig` and `UrlConfig`. This meant that if
you wanted your config to implement custom methods you had to monkey
patch `DatabaseConfigurations` to take a custom class into account. This
PR allows applications to register a custom db_config handler so that
custom configs can respond to needed methods. This is especially useful
for tools like Vitess where we may want to indicate it's sharded, but
not give Rails direct access to that knowledge.
Using the following database.yml as an example:
```yaml
development:
primary:
database: my_db
animals:
database: my_animals_db
vitess:
sharded: 1
```
We can register a custom handler that will generate `VitessConfig`
objects instead of a `HashConfig` object in an initializer:
```ruby
ActiveRecord::DatabaseConfigurations.register_db_config_handler do |env_name, name, url, config|
next unless config.key?(:vitess)
VitessConfig.new(env_name, name, config)
end
```
and create the `VitessConfig` class:
```ruby
class VitessConfig < ActiveRecord::DatabaseConfigurations::UrlConfig
def sharded?
vitess_config.fetch("sharded", false)
end
private
def vitess_config
configuration_hash.fetch(:vitess_config)
end
end
```
Now when the application is booted, the config with the `vitess` key
will generate a `VitessConfig` object where all others will generate a
`HashConfig`.
Things to keep in mind:
1) It is recommended but not required that these custom configs inherit
from Rails so you don't need to reimplement all the existing methods.
2) Applications must implement the configuration in which their config
should be used, otherwise first config wins (so all their configs
will be the custom one.)
3) The procs must support 4 arguments to accommodate `UrlConfig`. I am
thinking of deprecating this and forcing the URL parsing to happen in
the `UrlConfig` directly.
4) There is one tiny behavior change where when we have a nil url key in
the config hash we no longer merge it back into the configuration hash.
We also end up with a `HashConfig` instead of a `UrlConfig`. I think
this is fine because a `nil` URL is...useless.
Co-authored-by: John Crepezzi <john.crepezzi@gmail.com>
In `ToSql`, operators that generate the sql for an `Attribute` use `visit(o.left, collector)`
This can be seen in `Equality` (and friends), `Case`, `SelectStatement`, and `In`.
`HomogeneousIn` manually produces the sql for an `Attribute`, introduced in 72fd0bae
This change makes `HomogeneousIn` follow the pattern.
Before, it was using the configured by Rails. Having a mechanism to configure it
for Active Record encryption makes sense to prevent problems with encrypted content
when the default in Rails changes.
Additionally, there was a bug making AR encryption use the older SHA1 before
`ActiveSupport.hash_digest_class` got initialized to SHA256. This bug was exposed
by https://github.com/rails/rails/pull/44540. We will now set SHA256 as the standard
for 7.1+, and SHA1 for previous versions.
- Without this commit
```ruby
DEPRECATION WARNING: Passing the coder as positional argument is deprecated and will be remove in Rails 7.2.
Please pass the coder as a keyword argument:
serialize :foo, coder: JSON
(called from <class:User> at rep.rb:20)
DEPRECATION WARNING: Passing the class as positional argument is deprecated and will be remove in Rails 7.2.
Please pass the class as a keyword argument:
serialize :bar, type: Hash
(called from <class:User> at rep.rb:21)
```
- With this commit
```ruby
DEPRECATION WARNING: Passing the coder as positional argument is deprecated and will be remove in Rails 7.2.
Please pass the coder as a keyword argument:
serialize :foo, coder: JSON
(called from <class:User> at rep.rb:20)
DEPRECATION WARNING: Passing the class as positional argument is deprecated and will be remove in Rails 7.2.
Please pass the class as a keyword argument:
serialize :bar, type: Hash
(called from <class:User> at rep.rb:21)
```
With the universal adoption of UTF-8 in browsers, user facing text can
use more optimal Unicode typography. In digital and print design, using
RIGHT SINGLE QUOTATION MARK (U+2019) is normally preferred over
APOSTROPHE (U+0027) in contractions.
For details, see the Unicode Standard Section 6.2:
https://www.unicode.org/versions/Unicode13.0.0/ch06.pdf
> Punctuation Apostrophe. U+2019 right single quotation mark is
> preferred where the character is to represent a punctuation mark, as
> for contractions: “We’ve been here before.” In this latter case,
> U+2019 is also referred to as a punctuation apostrophe.
YAML is great for configuration and such, but for serializing arbitrary
data it has many problem, both in term of performance and efficiency
but also in term of security.
As such, we shouldn't let it be the default.
The open question is wether we should provide another default, or
just let users chose what they want based on their own tradeoffs.
Many people would probably suggest JSON as the new default, unfortunately
I don't think it's a good fit either because the parsers available in
Ruby have some wonky behaviors:
```ruby
>> ActiveSupport::JSON.decode(ActiveSupport::JSON.encode(Object.new))
=> {}
>> JSON.load(JSON.dump(Object.new))
=> "#<Object:0x000000012b61a068>"
```
If we were to select another default, I beleive it would need several
properties:
- It should only serialized a safe list of primitive types.
- It should explictly raise if attempting to serialize complex types.
* Remove Copyright years
* Basecamp is now 37signals... again
Co-authored-by: David Heinemeier Hansson <dhh@hey.com>
---------
Co-authored-by: David Heinemeier Hansson <dhh@hey.com>
YAML has quite a bit of footguns, as such it's desirable
to be able to substitute it for something else or even
simply to force users to define a serializer explictly for
every serialized columns.
Given an association like:
```ruby
BlogPost.has_many :blog_post_tags,
query_constraints: [:blog_id, :blog_post_id]
BlogPost.has_many :tags, through: :blog_post_tags
```
The `tags` association records can be queried
and the resulting JOIN query will include both `blog_id` and
`blog_post_id` in the ON clause.
