IMO we shouldn't encourage users to use methods they shouldn't need to know about. As Song (in this example) inherits from ActiveRecord, we can use super here instead to get the same effect with the bonus of not knowing how active record actually implements these methods.
…ric value is present. [ci skip] The way Active Record query methods handle numeric values is a special case, and is not part of Rails's standard definition of present. This update attempts to make this more clear in the docs, so that people don't expect Object#present? to return false if used on a number that is zero.
Update Active Record's attribute query methods documentation to clarify that whether an attribute is present is based on Object#present?. This gives people a place to go see what the exact definition of presence is. [ci skip]
…ibe its full behaviour. [ci skip]
This refactoring revealed the need for another form of decoration, which takes a proc to select which it applies to (There's a *lot* of cases where this form can be used). To avoid duplication, we can re-implement the old decoration in terms of the proc-based decoration. The reason we're `instance_exec`ing the matcher is for cases such as time zone aware attributes, where a decorator is defined in a parent class, and a method called in the matcher is overridden by a child class. The matcher will close over the parent, and evaluate in its context, which is not the behavior we want.
We need to decorate the types lazily. This is extracted to a separate API, as there are other refactorings that will be able to make use of it, and to allow unit testing the finer points more granularly.
As a result of all of the refactoring that's been done, it's now possible for us to define a public API to allow users to specify behavior. This is an initial implementation so that I can work off of it in smaller pieces for additional features/refactorings. The current behavior will continue to stay the same, though I'd like to refactor towards the automatic schema detection being built off of this API, and add the ability to opt out of automatic schema detection. Use cases: - We can deprecate a lot of the edge cases around types, now that there is an alternate path for users who wish to maintain the same behavior. - I intend to refactor serialized columns to be built on top of this API. - Gem and library maintainers are able to interact with `ActiveRecord` at a slightly lower level in a more stable way. - Interesting ability to reverse the work flow of adding to the schema. Model can become the single source of truth for the structure. We can compare that to what the database says the schema is, diff them, and generate a migration.
…t empty transactions. Closes #14841.
… values map to integers in the database, but can be queried by name