hoardable 0.14.2 → 0.15.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: befa1333fe9f96fa12949d58483241b3ea576cd21503cfb47586b22dbaf36fe4
-  data.tar.gz: '02390d38824b7fe05d5f8ffd9c8e0714d27da5b35d5fe4c2fee9e3f7775125fd'
+  metadata.gz: b2b34416224e686978b85cd78c0a80eae6e09f727a87c58060355671c6af8334
+  data.tar.gz: 401049a8d781e695fd691f1a9cf0c0ea67560c535efd773b738c40041ca80869
 SHA512:
-  metadata.gz: 83d0cb32b0363b0a1387e041301c6ddf9d55e40a8aa3d1c1d6c40416bdfb3c90115a0a37af25238474b96c0a54d9816f06ad5747b8f5d279d6af5aec09602e49
-  data.tar.gz: 2c8ca8c336cca19bc9f4e7199d6da3474df932415e6a481c1f6868df8b440e60820a68837bda8e137bd55922401950b646b0a8be94e4b0208854022befafff6e
+  metadata.gz: 3b39f34db9a87e2403b6a7529a035e0ccea464fbc6cda100b7069a2cc271e63112f0299dcae283e8b7c1d8f17e14892d58b9089e9e4b7fcc178cd94e808014a1
+  data.tar.gz: e2a8b1e9c9e5362711b2a5170a74d6316a115c290bf285e0ff60f3eed6937a4e4838000b2042a19bc79a97f3d7970882894bb519f244f6bac1eee1d1e529acac

data/.streerc

@@ -0,0 +1 @@
+--print-width=100

data/.tool-versions

@@ -1,2 +1,2 @@
-ruby 3.2.1
-postgres 14.4
+ruby 3.3.0
+postgres 16.1

data/CHANGELOG.md

@@ -1,3 +1,18 @@
+## 0.15.0
+
+- *Breaking Change* - Support for Ruby 2.7 and Rails 6.1 is dropped
+- *Breaking Change* - The default scoping clause that controls the inherited table SQL construction
+  changes from a where clause using `tableoid`s to using `FROM ONLY`
+- Fixes an issue for Rails 7.1 regarding accessing version table columns through aliased attributes
+- Fixes an issue where `Hoardable::RichText` couldn’t be loaded if `ActionText::RichText` wasn’t yet
+  loaded
+- Supports dumping `INHERITS (table_name)` options to `schema.rb` and ensures the inherited tables
+  are dumped after their parents
+
+## 0.14.3
+
+- The migration template is updated to make the primary key on the versions table its actual primary key
+
 ## 0.14.2
 
 - Fixes an eager loading issue regarding `ActionText::EncryptedRichText`

data/Gemfile

@@ -1,15 +1,14 @@
 # frozen_string_literal: true
 
-source 'https://rubygems.org'
+source "https://rubygems.org"
 
-gem 'benchmark-ips', '~> 2.10'
-gem 'debug', '~> 1.6'
-gem 'minitest', '~> 5.0'
-gem 'rails', '>= 6.1'
-gem 'rake', '~> 13.0'
-gem 'rubocop', '~> 1.21'
-gem 'rubocop-minitest', '~> 0.20'
-gem 'rubocop-rake', '~> 0.6'
-gem 'yard', '~> 0.9'
+gem "debug"
+if (rails_version = ENV["RAILS_VERSION"])
+  gem "rails", "~> #{rails_version}.0"
+else
+  gem "rails"
+end
+gem "syntax_tree"
+gem "typeprof"
 
 gemspec

data/README.md

@@ -1,21 +1,23 @@
 # Hoardable ![gem version](https://img.shields.io/gem/v/hoardable?style=flat-square)
 
-Hoardable is an ActiveRecord extension for Ruby 2.7+, Rails 6.1+, and PostgreSQL that allows for versioning
-and soft-deletion of records through the use of _uni-temporal inherited tables_.
+Hoardable is an ActiveRecord extension for Ruby 3+, Rails 7+, and PostgreSQL that allows for
+versioning and soft-deletion of records through the use of _uni-temporal inherited tables_.
 
-[Temporal tables](https://en.wikipedia.org/wiki/Temporal_database) are a database design pattern where each
-row of a table contains data along with one or more time ranges. In the case of this gem, each database row
-has a time range that represents the row’s valid time range - hence "uni-temporal".
+[Temporal tables](https://en.wikipedia.org/wiki/Temporal_database) are a database design pattern
+where each row of a table contains data along with one or more time ranges. In the case of this gem,
+each database row has a time range that represents the row’s valid time range - hence
+"uni-temporal".
 
-[Table inheritance](https://www.postgresql.org/docs/14/ddl-inherit.html) is a feature of PostgreSQL that
-allows a table to inherit all columns of a parent table. The descendant table’s schema will stay in sync with
-its parent. If a new column is added to or removed from the parent, the schema change is reflected on its
-descendants.
+[Table inheritance](https://www.postgresql.org/docs/current/ddl-inherit.html) is a feature of
+PostgreSQL that allows a table to inherit all columns of a parent table. The descendant table’s
+schema will stay in sync with its parent. If a new column is added to or removed from the parent,
+the schema change is reflected on its descendants.
 
-With these concepts combined, `hoardable` offers a simple and effective model versioning system for Rails.
-Versions of records are stored in separate, inherited tables along with their valid time ranges and
-contextual data. Compared to other Rails-oriented versioning systems, this gem strives to be more explicit
-and obvious on the lower database level, while still familiar and convenient to use within Ruby on Rails.
+With these concepts combined, `hoardable` offers a model versioning and soft deletion system for
+Rails. Versions of records are stored in separate, inherited tables along with their valid time
+ranges and contextual data. Compared to other Rails-oriented versioning systems, this gem strives to
+be more explicit and obvious on the lower database level, while still familiar and convenient to use
+within Ruby on Rails.
 
 [👉 Documentation](https://www.rubydoc.info/gems/hoardable)
 
@@ -34,12 +36,10 @@ bin/rails g hoardable:install
 bin/rails db:migrate
 ```
 
-This will generate PostgreSQL functions, an enum and an initiailzer. It will also set
-`config.active_record.schema_format = :sql` in `application.rb` if you are using Rails < 7.
-
 ### Model Installation
 
-You must include `Hoardable::Model` into an ActiveRecord model that you would like to hoard versions of:
+You must include `Hoardable::Model` into an ActiveRecord model that you would like to hoard versions
+of:
 
 ```ruby
 class Post < ActiveRecord::Base
@@ -55,31 +55,33 @@ bin/rails g hoardable:migration Post
 bin/rails db:migrate
 ```
 
-By default, it will guess the foreign key type for the `_versions` table based on the primary key of the
-model specified in the migration generator above. If you want/need to specify this explicitly, you can do so:
+By default, it will guess the foreign key type for the `_versions` table based on the primary key of
+the model specified in the migration generator above. If you want/need to specify this explicitly,
+you can do so:
 
 ```
 bin/rails g hoardable:migration Post --foreign-key-type uuid
 ```
 
-_Note:_ Creating an inherited table does not inherit the indexes from the parent table. If you need to query
-versions often, you should add appropriate indexes to the `_versions` tables.
+_*Note*:_ Creating an inherited table does not inherit the indexes from the parent table. If you
+need to query versions often, you should add appropriate indexes to the `_versions` tables. See
+[here](https://github.com/waymondo/hoardable/issues/30) for more info.
 
 ## Usage
 
 ### Overview
 
-Once you include `Hoardable::Model` into a model, it will dynamically generate a "Version" subclass of that
-model. As we continue our example from above:
+Once you include `Hoardable::Model` into a model, it will dynamically generate a "Version" subclass
+of that model. As we continue our example from above:
 
 ```ruby
-Post #=> Post(id: integer, created_at: datetime, updated_at: datetime, hoardable_id: integer)
-PostVersion #=> PostVersion(id: integer, created_at: datetime, updated_at: datetime, hoardable_id: integer, _data: jsonb, _during: tsrange, _event_uuid: uuid, _operation: enum)
+Post #=> Post(id: integer, ..., hoardable_id: integer)
+PostVersion #=> PostVersion(id: integer, ..., hoardable_id: integer, _data: jsonb, _during: tsrange, _event_uuid: uuid, _operation: enum)
 Post.version_class #=> same as `PostVersion`
 ```
 
-A `Post` now `has_many :versions`. With the default configuration, whenever an update and deletion of a
-`Post` occurs, a version is created:
+A `Post` now `has_many :versions`. With the default configuration, whenever an update or deletion of
+a `post` occurs, a version is created:
 
 ```ruby
 post = Post.create!(title: "Title")
@@ -96,7 +98,7 @@ Post.find(post.id) # raises ActiveRecord::RecordNotFound
 Each `PostVersion` has access to the same attributes, relationships, and other model behavior that
 `Post` has, but as a read-only record:
 
-``` ruby
+```ruby
 post.versions.last.update!(title: "Rewrite history") #=> raises ActiveRecord::ReadOnlyRecord
 ```
 
@@ -105,12 +107,15 @@ If you ever need to revert to a specific version, you can call `version.revert!`
 ```ruby
 post = Post.create!(title: "Title")
 post.update!(title: "Whoops")
-post.reload.versions.last.revert!
+version = post.reload.versions.last
+version.title # -> "Title"
+version.revert!
 post.title # => "Title"
 ```
 
-If you would like to untrash a specific version of a record you deleted, you can call `version.untrash!` on
-it. This will re-insert the model in the parent class’s table with the original primary key.
+If you would like to untrash a specific version of a record you deleted, you can call
+`version.untrash!` on it. This will re-insert the model in the parent class’s table with the
+original primary key.
 
 ```ruby
 post = Post.create!(title: "Title")
@@ -124,13 +129,24 @@ trashed_post.untrash!
 Post.find(post.id) # #<Post>
 ```
 
-_Note:_ You will notice above that both `posts` and `post_versions` pull from the same ID sequence. This
-allows for uniquely identifying source records and versions when results are mixed together. Both a source
-record and versions have an automatically managed `hoardable_id` that always represents the primary key value
-of the original source record.
+_*Note*:_ You will notice above that both `posts` and `post_versions` pull from the same ID
+sequence. This allows for uniquely identifying source records and versions when results are mixed
+together. Both a source record and versions have an automatically managed `hoardable_id` that always
+represents the primary key value of the original source record.
 
 ### Querying and Temporal Lookup
 
+Including `Hoardable::Model` into your source model modifies its default scope to make sure you only
+query the parent table:
+
+```ruby
+Post.where(state: :draft).to_sql # => SELECT posts.* FROM ONLY posts WHERE posts.status = 'draft'
+```
+
+_*Note*:_ If you are executing raw SQL, you will need to include the `ONLY` keyword you see above to
+the select statement if you do not wish to return versions in the results. Learn more about table
+inheritance in [the PostgreSQL documentation](https://www.postgresql.org/docs/current/ddl-inherit.html).
+
 Since a `PostVersion` is an `ActiveRecord` class, you can query them like another model resource:
 
 ```ruby
@@ -152,32 +168,34 @@ The source model class also has an `.at` method:
 Post.at(1.day.ago) # => [#<Post>, #<Post>]
 ```
 
-This will return an ActiveRecord scoped query of all `Post` and `PostVersion` records that were valid at that
-time, all cast as instances of `Post`.
+This will return an ActiveRecord scoped query of all `Post` and `PostVersion` records that were
+valid at that time, all cast as instances of `Post`.
 
-There is also an `at` method on `Hoardable` itself for more complex and experimental temporal resource
-querying. See [Relationships](#relationships) for more.
+There is also an `at` method on `Hoardable` itself for more complex and experimental temporal
+resource querying. See [Relationships](#relationships) for more.
 
-By default, `hoardable` will keep copies of records you have destroyed. You can query them specifically with:
+By default, `hoardable` will keep copies of records you have destroyed. You can query them
+specifically with:
 
 ```ruby
-PostVersion.trashed
-Post.version_class.trashed # <- same as above
+PostVersion.trashed.where(user_id: user.id)
+Post.version_class.trashed.where(user_id: user.id) # <- same as above
 ```
 
-_Note:_ A `Version` is not created upon initial parent model creation. To accurately track the beginning of
-the first temporal period, you will need to ensure the source model table has a `created_at` timestamp
-column. If this is missing, an error will be raised.
+_*Note*:_ A `Version` is not created upon initial source model creation. To accurately track the
+beginning of the first temporal period, you will need to ensure the source model table has a
+`created_at` timestamp column. If this is missing, an error will be raised.
 
 ### Tracking Contextual Data
 
-You’ll often want to track contextual data about the creation of a version. There are 2 options that can be
-provided for tracking contextual information:
+You’ll often want to track contextual data about the creation of a version. There are 2 options that
+can be provided for tracking this:
 
-- `:whodunit` - an identifier for who is responsible for creating the version
+- `:whodunit` - an identifier for who/what is responsible for creating the version
 - `:meta` - any other contextual information you’d like to store along with the version
 
-This information is stored in a `jsonb` column. Each key’s value can be in the format of your choosing.
+This information is stored in a `jsonb` column. Each key’s value can be in the format of your
+choosing.
 
 One convenient way to assign contextual data to these is by defining a proc in an initializer, i.e.:
 
@@ -186,22 +204,23 @@ One convenient way to assign contextual data to these is by defining a proc in a
 Hoardable.whodunit = -> { Current.user&.id }
 
 # somewhere in your app code
-Current.user = User.find(123)
-post.update!(status: 'live')
-post.reload.versions.last.hoardable_whodunit # => 123
+Current.set(user: User.find(123)) do
+  post.update!(status: :live)
+  post.reload.versions.last.hoardable_whodunit # => 123
+end
 ```
 
-You can also set this context manually as well:
+You can also set these context values manually as well:
 
 ```ruby
-Hoardable.meta = { note: "reverting due to accidental deletion" }
+Hoardable.meta = {note: "reverting due to accidental deletion"}
 post.update!(title: "We’re back!")
 Hoardable.meta = nil
 post.reload.versions.last.hoardable_meta['note'] # => "reverting due to accidental deletion"
 ```
 
-A more useful pattern however is to use `Hoardable.with` to set the context around a block. For example, you
-could have the following in your `ApplicationController`:
+A more useful pattern would be to use `Hoardable.with` to set the context around a block. For
+example, you could have the following in your `ApplicationController`:
 
 ```ruby
 class ApplicationController < ActionController::Base
@@ -210,7 +229,7 @@ class ApplicationController < ActionController::Base
   private
 
   def use_hoardable_context
-    Hoardable.with(whodunit: current_user.id, meta: { request_uuid: request.uuid }) do
+    Hoardable.with(whodunit: current_user.id, meta: {request_uuid: request.uuid}) do
       yield
     end
     # `Hoardable.whodunit` and `Hoardable.meta` are back to nil or their previously set values
@@ -219,9 +238,10 @@ end
 ```
 
 `hoardable` will also automatically capture the ActiveRecord
-[changes](https://api.rubyonrails.org/classes/ActiveModel/Dirty.html#method-i-changes) hash, the `operation`
-that cause the version (`update` or `delete`), and it will also tag all versions created in the same database
-transaction with a shared and unique `event_uuid` for that transaction. These are available as:
+[changes](https://api.rubyonrails.org/classes/ActiveModel/Dirty.html#method-i-changes) hash, the
+`operation` that cause the version (`update` or `delete`), and it will also tag all versions created
+in the same database transaction with a shared and unique `event_uuid` for that transaction. These
+values are available as:
 
 ```ruby
 version.changes
@@ -231,12 +251,12 @@ version.hoardable_event_uuid
 
 ### Model Callbacks
 
-Sometimes you might want to do something with a version after it gets inserted to the database. You can
-access it in `after_versioned` callbacks on the source record as `hoardable_version`. These happen within
-`ActiveRecord`’s `.save`, which is enclosed in an ActiveRecord transaction.
+Sometimes you might want to do something with a version after it gets inserted to the database. You
+can access it in `after_versioned` callbacks on the source record as `hoardable_version`. These
+happen within `ActiveRecord`’s `.save`, which is enclosed in an ActiveRecord transaction.
 
-There are also `after_reverted` and `after_untrashed` callbacks available as well, which are called on the
-source record after a version is reverted or untrashed.
+There are also `after_reverted` and `after_untrashed` callbacks available as well, which are called
+on the source record after a version is reverted or untrashed.
 
 ```ruby
 class User
@@ -275,14 +295,15 @@ Hoardable.save_trash # => default true
 
 `Hoardable.version_updates` globally controls whether versions get created on record updates.
 
-`Hoardable.save_trash` globally controls whether to create versions upon record deletion. When this is set to
-`false`, all versions of a record will be deleted when the record is destroyed.
+`Hoardable.save_trash` globally controls whether to create versions upon source record deletion.
+When this is set to `false`, all versions of a source record will be deleted when the record is
+destroyed.
 
 If you would like to temporarily set a config setting, you can use `Hoardable.with`:
 
 ```ruby
 Hoardable.with(enabled: false) do
-  post.update!(title: 'unimportant change to create version for')
+  post.update!(title: "replace title without creating a version")
 end
 ```
 
@@ -304,17 +325,17 @@ Comment.with_hoardable_config(version_updates: true) do
 end
 ```
 
-If a model-level option exists, it will use that. Otherwise, it will fall back to the global `Hoardable`
-config.
+If a model-level option exists, it will use that. Otherwise, it will fall back to the global
+`Hoardable` config.
 
 ## Relationships
 
 ### Belongs To Trashable
 
-Sometimes you’ll have a record that belongs to a parent record that you’ll trash. Now the child record’s
-foreign key will point to the non-existent trashed version of the parent. If you would like to have
-`belongs_to` resolve to the trashed parent model in this case, you can give it the option of `trashable:
-true`:
+Sometimes you’ll have a record that belongs to a parent record that you’ll trash. Now the child
+record’s foreign key will point to the non-existent trashed version of the parent. If you would like
+to have `belongs_to` resolve to the trashed parent model in this case, you can give it the option of
+`trashable: true`:
 
 ```ruby
 class Comment
@@ -335,21 +356,21 @@ class Post
   has_many :comments, hoardable: true
 end
 
-def Comment
+class Comment
   include Hoardable::Model
 end
 
-post = Post.create!(title: 'Title')
-comment1 = post.comments.create!(body: 'Comment')
-comment2 = post.comments.create!(body: 'Comment')
+post = Post.create!(title: "Title")
+comment1 = post.comments.create!(body: "Comment")
+comment2 = post.comments.create!(body: "Comment")
 datetime = DateTime.current
 comment2.destroy!
-post.update!(title: 'New Title')
+post.update!(title: "New Title")
 post_id = post.id # 1
 
 Hoardable.at(datetime) do
   post = Post.find(post_id)
-  post.title # => 'Title'
+  post.title # => "Title"
   post.comments.size # => 2
   post.id # => 2
   post.version? # => true
@@ -357,26 +378,26 @@ Hoardable.at(datetime) do
 end
 ```
 
-There are some additional details to point out above. Firstly, it is important to note that the final
-`post.id` yields a different value than the originally created `Post`. This is because the `post` within the
-`#at` block is actually a temporal version, since it has been subsequently updated, but is reified as a
-`Post` for the purposes of your business logic (serialization, rendering views, exporting, etc). Don’t fret -
-you will not be able to commit any updates to the version, even though it is masquerading as a `Post` because
-a database trigger won’t allow you to.
+You’ll notice above that the `post` within the `#at` block is actually a temporal `post_version`,
+since it has been subsequently updated and has a different id - it is reified as a `post` for the
+purposes of your business logic (serialization, rendering views, exporting, etc). Don’t fret - you
+will not be able to commit any updates to the version, even though it is masquerading as a `Post`
+because a database trigger won’t allow it.
 
-If you are ever unsure if a Hoardable record is a source record or a version, you can be sure by calling
-`version?` on it. If you want to get the true original source record ID, you can call `hoardable_id`.
+If you are ever unsure if a Hoardable record is a source record or a version, you can be sure by
+calling `version?` on it. If you want to get the true original source record ID, you can call
+`hoardable_id`.
 
-_Note:_ `Hoardable.at` is still very experimental and is potentially not very performant for querying large
-data sets.
+_*Note*:_ `Hoardable.at` is still very experimental and is potentially not performant for querying
+large data sets.
 
 ### Cascading Untrashing
 
-Sometimes you’ll trash something that `has_many :children, dependent: :destroy` and if you untrash the parent
-record, you’ll want to also untrash the children. Whenever a hoardable version is created in a database
-transaction, it will create or re-use a unique event UUID for the current database transaction and tag all
-versions created with it. That way, when you `untrash!` a record, you could find and `untrash!` records that
-were trashed with it:
+Sometimes you’ll trash something that `has_many :children, dependent: :destroy` and if you untrash
+the parent record, you’ll want to also untrash the children. Whenever a hoardable version is created
+in a database transaction, it will create or re-use a unique event UUID for the current database
+transaction and tag all versions created with it. That way, when you `untrash!` a record, you could
+find and `untrash!` records that were trashed with it:
 
 ```ruby
 class Post < ActiveRecord::Base
@@ -395,20 +416,22 @@ end
 
 ### Action Text
 
-Hoardable provides support for ActiveRecord models with `has_rich_text`. First, you must create a temporal
-table for `ActionText::RichText`:
+Hoardable provides support for ActiveRecord models with `has_rich_text`. First, you must create a
+temporal table for `ActionText::RichText`:
 
 ```
 bin/rails g hoardable:migration ActionText::RichText
 bin/rails db:migrate
 ```
 
-Then in your model include `Hoardable::Model` and provide the `hoardable: true` keyword to `has_rich_text`:
+Then in your model include `Hoardable::Model` and provide the `hoardable: true` keyword to
+`has_rich_text`:
 
 ```ruby
 class Post < ActiveRecord::Base
   include Hoardable::Model # or `Hoardable::Associations` if you don't need `PostVersion`
   has_rich_text :content, hoardable: true
+  # alternately, this could be `has_hoardable_rich_text :content`
 end
 ```
 
@@ -431,62 +454,64 @@ end
 
 Rails uses a method called
 [`disable_referential_integrity`](https://github.com/rails/rails/blob/06e9fbd954ab113108a7982357553fdef285bff1/activerecord/lib/active_record/connection_adapters/postgresql/referential_integrity.rb#L7)
-when inserting fixtures into the database. This disables PostgreSQL triggers, which Hoardable relies on for
-assigning `hoardable_id` from the primary key’s value. If you would still like to use fixtures, you must
-specify the primary key’s value and `hoardable_id` to the same identifier value in the fixture. This is not
-an issue with fixture replacement libraries like `factory_bot` or
+when inserting fixtures into the database. This disables PostgreSQL triggers, which Hoardable relies
+on for assigning `hoardable_id` from the primary key’s value. If you would still like to use
+fixtures, you must specify the primary key’s value and `hoardable_id` to the same identifier value
+in the fixture. This is not an issue with fixture replacement libraries like `factory_bot` or
 [`world_factory`](https://github.com/FutureProofRetail/world_factory) however.
 
 ## Gem Comparison
 
 #### [`paper_trail`](https://github.com/paper-trail-gem/paper_trail)
 
-`paper_trail` is maybe the most popular and fully featured gem in this space. It works for other database
-types than PostgeSQL and (by default) stores all versions of all versioned models in a single `versions`
-table. It stores changes in a `text`, `json`, or `jsonb` column. In order to efficiently query the `versions`
-table, a `jsonb` column should be used, which takes up a lot of space to index. Unless you customize your
-configuration, all `versions` for all models types are in the same table which is inefficient if you are only
-interested in querying versions of a single model. By contrast, `hoardable` stores versions in smaller,
-isolated and inherited tables with the same database columns as their parents, which are more efficient for
-querying as well as auditing for truncating and dropping. The concept of a `temporal` time-frame does not
-exist for a single version since there is only a `created_at` timestamp.
+`paper_trail` is maybe the most popular and fully featured gem in this space. It works for other
+database types than PostgeSQL. Bby default it stores all versions of all versioned models in a
+single `versions` table. It stores changes in a `text`, `json`, or `jsonb` column. In order to
+efficiently query the `versions` table, a `jsonb` column should be used, which can take up a lot of
+space to index. Unless you customize your configuration, all `versions` for all models types are in
+the same table which is inefficient if you are only interested in querying versions of a single
+model. By contrast, `hoardable` stores versions in smaller, isolated, inherited tables with the same
+database columns as their parents, which are more efficient for querying as well as auditing for
+truncating and dropping. The concept of a temporal timeframe does not exist for a single version
+since there is only a `created_at` timestamp.
 
 #### [`audited`](https://github.com/collectiveidea/audited)
 
-`audited` works in a similar manner as `paper_trail`. It stores all versions for all model types in a single
-table, you must opt into using `jsonb` as the column type to store "changes", in case you want to query them,
-and there is no concept of a `temporal` time-frame for a single version. It makes opinionated decisions about
-contextual data requirements and stores them as top level data types on the `audited` table.
+`audited` works in a similar manner as `paper_trail`. It stores all versions for all model types in
+a single table, you must opt into using `jsonb` as the column type to store "changes", in case you
+want to query them, and there is no concept of a temporal timeframe for a single version. It makes
+opinionated decisions about contextual data requirements and stores them as top level data types on
+the `audited` table.
 
 #### [`discard`](https://github.com/jhawthorn/discard)
 
-`discard` only covers soft-deletion. The act of "soft deleting" a record is only captured through the
-time-stamping of a `discarded_at` column on the records table; there is no other capturing of the event that
-caused the soft deletion unless you implement it yourself. Once the "discarded" record is restored, the
-previous "discarded" awareness is lost. Since "discarded" records exist in the same table as "undiscarded"
-records, you must explicitly omit the discarded records from queries across your app to keep them from
-leaking in.
+`discard` only covers soft-deletion. The act of "soft deleting" a record is only captured through
+the time-stamping of a `discarded_at` column on the records table. There is no other capturing of
+the event that caused the soft deletion unless you implement it yourself. Once the "discarded"
+record is restored, the previous "discarded" awareness is lost. Since "discarded" records exist in
+the same table as "undiscarded" records, you must explicitly omit the discarded records from queries
+across your app to keep them from leaking in.
 
 #### [`paranoia`](https://github.com/rubysherpas/paranoia)
 
-`paranoia` also only covers soft-deletion. In their README, they recommend using `discard` instead of
-`paranoia` because of the fact they override ActiveRecord’s `delete` and `destroy` methods. `hoardable`
-employs callbacks to create trashed versions instead of overriding methods. Otherwise, `paranoia` works
-similarly to `discard` in that it keeps deleted records in the same table and tags them with a `deleted_at`
-timestamp. No other information about the soft-deletion event is stored.
+`paranoia` also only covers soft-deletion. In their README, they recommend using `discard` instead
+of `paranoia` because of the fact they override ActiveRecord’s `delete` and `destroy` methods.
+`hoardable` employs callbacks to create trashed versions instead of overriding methods. Otherwise,
+`paranoia` works similarly to `discard` in that it keeps deleted records in the same table and tags
+them with a `deleted_at` timestamp. No other information about the soft-deletion event is stored.
 
 #### [`logidze`](https://github.com/palkan/logidze)
 
-`logidze` is an interesting versioning alternative that leverages the power of PostgreSQL triggers. Instead
-of storing the previous versions or changes in a separate table, it stores them in a proprietary JSON format
-directly on the database row of the record itself. If does not support soft deletion.
+`logidze` is an interesting versioning alternative that leverages the power of PostgreSQL triggers.
+Instead of storing the previous versions or changes in a separate table, it stores them in a
+proprietary JSON format directly on the database row of the record itself. If does not support soft
+deletion.
 
 ## Contributing
 
-This gem still quite new and very open to feedback.
-
 Bug reports and pull requests are welcome on GitHub at https://github.com/waymondo/hoardable.
 
 ## License
 
-The gem is available as open source under the terms of the [MIT License](https://opensource.org/licenses/MIT).
+The gem is available as open source under the terms of the [MIT
+License](https://opensource.org/licenses/MIT).

data/Rakefile

@@ -1,16 +1,30 @@
 # frozen_string_literal: true
 
-require 'bundler/gem_tasks'
-require 'rake/testtask'
+require "bundler/gem_tasks"
+require "rake/testtask"
+require "syntax_tree/rake_tasks"
 
 Rake::TestTask.new(:test) do |t|
-  t.libs << 'test'
-  t.libs << 'lib'
-  t.test_files = FileList['test/**/test_*.rb']
+  t.libs << "test"
+  t.libs << "lib"
+  t.test_files = FileList["test/**/test_*.rb"]
 end
 
-require 'rubocop/rake_task'
+SOURCE_FILES = %w[test/**/*.rb lib/**/*.rb Rakefile Gemfile bin/console hoardable.gemspec]
 
-RuboCop::RakeTask.new
+SyntaxTree::Rake::CheckTask.new(:check) do |t|
+  t.source_files = SOURCE_FILES
+  t.print_width = 100
+end
+
+SyntaxTree::Rake::WriteTask.new(:write) do |t|
+  t.source_files = SOURCE_FILES
+  t.print_width = 100
+end
+
+task :typeprof do
+  `typeprof lib/hoardable.rb`
+end
 
-task default: %i[test rubocop]
+task default: %i[check test]
+task pre_commit: %i[write typeprof]