I'm hoping we don't actually need it because we explicitly enable
fractional seconds precision in our `dummy_app` migration by
specifying `limit(6)`.
Works on my machine, but I use mariadb. We'll see how well it works
on TravisCI, which runs mysql 5.6.33.
MySQL added support for `limit(6)` in 5.6.4, so I'm hopeful.
* integrate versioning into AR touch method
* add touch to list of :on events, deprecate touch_with_version
* integrate versioning into AR touch method
The reason some projects have both is so that some spec files can be
run in isolation, without the rails stuff. In practice, I don't find
myself ever doing this. So, the complexity of two files is unnecessary.
Fixes#798
Our test suite has one model that tests enums, PostWithStatus. Its
spec did not cover `touch_with_version`. Somehow, probably during
our upgrade to rails 5, we broke `touch_with_version` for enums.
Unlike other methods, when an enum arrives at
`CastAttributeSerializer#serialize` during `touch_with_version`, it
is already a number. We assumed it was always a string.
This is sort of a hack, just handling both strings and numbers in
`#serialize`. I'd rather figure out how a number got to `#serialize`
in the first place. However, a hack is acceptable, as it's only
for rails 4.2, and the hack will eventually be deleted when we
drop support for 4.2.
Problem
-------
`has_paper_trail` adds too many methods to the ActiveRecord model.
> If I'm counting correctly, installing the paper_trail gem adds 36 instance
> methods and 10 class methods to all of your active record models. Of those
> 46, 13 have a prefix, either "pt_" or "paper_trail_". I don't know what the
> best way to deal with this is. Ideally, we'd add far fewer methods to
> people's models. If we were able to add fewer methods to models, then I
> wouldn't mind prefixing all of them.
> https://github.com/airblade/paper_trail/issues/703
Solution
--------
Add only two methods to the AR model.
1. An instance method `#paper_trail`
2. A class method `.paper_trail`
The instance method would return a `RecordTrail` and the class method would
return a `ClassTrail`. Those names are totally up for debate.
Advantages
----------
- Plain ruby, easy to understand
- Adding new methods to e.g. the `RecordTrail` does not add any methods to
the AR model.
- Methods privacy is more strongly enforced.
- Enables isolated testing of e.g. `RecordTrail`; it can be constructed with a
mock AR instance.
Disadvantages
-------------
- Two new classes, though they are simple.
Keep consistency between versions with regard to `changes` and
`object_changes` and how enum columns store their values.
Before, `changes` would map the changed attributes enum columns to the database
values (integer values). This allows reifying that version to maintain the
integrity of the enum. It did not do so for `object_changes` and thus, `0`
for non-json columns, and the enum value for json columns would be stored instead.
For the non-json columns, it mapped any non-integer enum value to `0` because
during serialization that column is an `integer`. Now this is fixed,
so that `object_changes` stores the enum mapped value.
Here is an example:
```ruby
class PostWithStatus < ActiveRecord::Base
has_paper_trail
enum status: { draft: 0, published: 1, archived: 2 }
end
post = PostWithStatus.new(status: :draft)
post.published!
version = post.versions.last
# Before
version.changeset #> { 'status' => ['draft', 'draft'] } (stored as [0, 0])
# After
version.changeset #> { 'status' => ['draft', 'published'] } (stored as [0, 1])
```
Jared Beck