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.
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.
Jared Beck