hoardable 0.12.9 → 0.14.0

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: f56e0b270664927191148ea5ad8bcf4f4511c482c1964d4746f31513eb23b25f
-  data.tar.gz: b69b35c7aa7f3eb013b1444c3b26115f012c8a7617ba457ce248074eca2706e0
+  metadata.gz: 83017b15a9b37931d02d7f5d8b7b8d3e81cab4b4cc4691f522430ae2c9be77f8
+  data.tar.gz: 1774bb8cfe7628bbc2bdd8293928dac45dce20c4724aa5c4bc435a4c59a40f0d
 SHA512:
-  metadata.gz: 39c6176733cb67efc47e9d7985fa30427090e02c21c6abb6d54e9d2b88c975c430b4e0eafa4976457704a16c1fd8ef68c0245269f67adf0cf4a13d4e5a42c2f4
-  data.tar.gz: 975229330ca851b4d847113a3e76bd0a0ff59a86cf39a5cfa73e11f456d475a0b51df82a90ab51a6035ab1f934ce7fa87607925679fd620c4dab25ec44979cf4
+  metadata.gz: d0b7d0024a9b8eee5982ab92af174a9a7a134445108c1c3d97945c5ad967f234743fe047f0c42726366d38b7facacc44bac530a5de9a5369de0a9e7bc27342f9
+  data.tar.gz: fb4d0de48b7d798e70c948aea4ae8adb90eaa2836c4ca2d76e952e5c02d53951205f2628bc3e620cb1824f6ac49fcc692dc19130f907c932e0ed3b78fee217e8

data/.rubocop.yml

@@ -1,5 +1,5 @@
 AllCops:
-  TargetRubyVersion: 2.6
+  TargetRubyVersion: 2.7
   NewCops: enable
   SuggestExtensions: false
 

data/.tool-versions

@@ -1,2 +1,2 @@
-ruby 3.1.2
+ruby 3.2.1
 postgres 14.4

data/CHANGELOG.md

@@ -1,4 +1,6 @@
-## [Unreleased]
+## 0.14.0
 
-- Stability is coming.
+- *Breaking Change* - Support for Ruby 2.6 is dropped
+- Adjusts the migration and install generators to use the `fx` gem so that Rails 7+ can use `schema.rb`
+  instead of `structure.sql`
 

data/README.md

@@ -1,23 +1,21 @@
 # Hoardable ![gem version](https://img.shields.io/gem/v/hoardable?style=flat-square)
 
-Hoardable is an ActiveRecord extension for Ruby 2.6+, 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 2.7+, Rails 6.1+, 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/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.
 
-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 RDBS level while still familiar and convenient to use
-within Ruby on Rails.
+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.
 
 [👉 Documentation](https://www.rubydoc.info/gems/hoardable)
 
@@ -36,19 +34,16 @@ bin/rails g hoardable:install
 bin/rails db:migrate
 ```
 
-This will generate PostgreSQL functions, an initiailzer, and set `config.active_record.schema_format
-= :sql` in `application.rb`.
+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
   include Hoardable::Model
-  belongs_to :user
-  has_many :comments, dependent: :destroy
   ...
 end
 ```
@@ -60,34 +55,31 @@ bin/rails g hoardable:migration Post
 bin/rails db:migrate
 ```
 
-By default, it will try to 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 copy over 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.
 
 ## 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:
 
-```
-$ irb
->> Post
-=> Post(id: integer, body: text, user_id: integer, created_at: datetime, hoardable_id: integer)
->> PostVersion
-=> PostVersion(id: integer, body: text, user_id: integer, created_at: datetime, hoardable_id: integer, _data: jsonb, _during: tsrange)
+```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.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 and deletion of a
+`Post` occurs, a version is created:
 
 ```ruby
 post = Post.create!(title: "Title")
@@ -102,7 +94,11 @@ 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.
+`Post` has, but as a read-only record:
+
+``` ruby
+post.versions.last.update!(title: "Rewrite history") #=> raises ActiveRecord::ReadOnlyRecord
+```
 
 If you ever need to revert to a specific version, you can call `version.revert!` on it.
 
@@ -113,8 +109,8 @@ post.reload.versions.last.revert!
 post.title # => "Title"
 ```
 
-If you would like to untrash a specific version, 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")
@@ -128,12 +124,17 @@ 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.
+
 ### Querying and Temporal Lookup
 
 Since a `PostVersion` is an `ActiveRecord` class, you can query them like another model resource:
 
 ```ruby
-post.versions.where(user_id: Current.user.id, body: "Cool!")
+post.versions.where(state: :draft)
 ```
 
 If you want to look-up the version of a record at a specific time, you can use the `.at` method:
@@ -141,7 +142,8 @@ If you want to look-up the version of a record at a specific time, you can use t
 ```ruby
 post.at(1.day.ago) # => #<PostVersion>
 # or you can use the scope on the version model class
-PostVersion.at(1.day.ago).find_by(hoardable_id: post.id) # => #<PostVersion>
+post.versions.at(1.day.ago) # => #<PostVersion>
+PostVersion.at(1.day.ago).find_by(hoardable_id: post.id) # => same as above
 ```
 
 The source model class also has an `.at` method:
@@ -150,35 +152,32 @@ 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 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 thing as above
+Post.version_class.trashed # <- 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 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.
 
 ### Tracking Contextual Data
 
-You’ll often want to track contextual data about the creation of a version. There are 3 optional
-symbol keys that are 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 contextual information:
 
 - `:whodunit` - an identifier for who is responsible for creating the version
-- `:note` - a description regarding the versioning
 - `: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.:
 
@@ -192,17 +191,17 @@ post.update!(status: 'live')
 post.reload.versions.last.hoardable_whodunit # => 123
 ```
 
-You can also set this context manually as well, just remember to clear them afterwards.
+You can also set this context manually as well:
 
 ```ruby
-Hoardable.note = "reverting due to accidental deletion"
+Hoardable.meta = { note: "reverting due to accidental deletion" }
 post.update!(title: "We’re back!")
-Hoardable.note = nil
-post.reload.versions.last.hoardable_note # => "reverting due to accidental deletion"
+Hoardable.meta = nil
+post.reload.versions.last.hoardable_meta['note'] # => "reverting due to accidental deletion"
 ```
 
-A more useful pattern is to use `Hoardable.with` to set the context around a block. A good example
-of this would be in `ApplicationController`:
+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`:
 
 ```ruby
 class ApplicationController < ActionController::Base
@@ -220,9 +219,9 @@ 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`. 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 are available as:
 
 ```ruby
 version.changes
@@ -232,12 +231,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
@@ -272,11 +271,11 @@ Hoardable.version_updates # => default true
 Hoardable.save_trash # => default true
 ```
 
-`Hoardable.enabled` controls whether versions will be ever be created.
+`Hoardable.enabled` globally controls whether versions will be ever be created.
 
-`Hoardable.version_updates` controls whether versions get created on record updates.
+`Hoardable.version_updates` globally controls whether versions get created on record updates.
 
-`Hoardable.save_trash` controls whether to create versions upon record deletion. When this is set to
+`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.
 
 If you would like to temporarily set a config setting, you can use `Hoardable.with`:
@@ -287,7 +286,7 @@ Hoardable.with(enabled: false) do
 end
 ```
 
-You can also configure these variables per `ActiveRecord` class as well using `hoardable_config`:
+You can also configure these settings per `ActiveRecord` class using `hoardable_config`:
 
 ```ruby
 class Comment < ActiveRecord::Base
@@ -305,18 +304,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
+## Relationships
 
-As in life, sometimes relationships can be hard, but here are some pointers on handling associations
-with `Hoardable` considerations.
+### 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
@@ -325,10 +323,11 @@ class Comment
 end
 ```
 
-Sometimes you'll have a Hoardable record that `has_many` other Hoardable records and you will want
-to know the state of both the parent record and the children at a cetain point in time. You
-accomplish this by adding `hoardable: true` to the `has_many` relationship and using the
-`Hoardable.at` method:
+### Hoardable Has Many & Has One
+
+Sometimes you'll have a Hoardable record that `has_one` or `has_many` other Hoardable records and you will
+want to know the state of both the parent record and the children at a cetain point in time. You accomplish
+this by adding `hoardable: true` to the `has_many` relationship and using the `Hoardable.at` method:
 
 ```ruby
 class Post
@@ -358,22 +357,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 it has been 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`.
+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.
 
-If you are ever unsure if a Hoardable record is a "source" 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`.
 
-Sometimes you’ll trash something that `has_many :children, dependent: :destroy` and want
-to untrash everything in a similar dependent manner. Whenever a hoardable version is created in a
-database transaction, it will create or re-use a unique event UUID for that transaction and tag all
-versions created with it. That way, when you `untrash!` a record, you can find and `untrash!`
-records that were trashed with it:
+_Note:_ `Hoardable.at` is still very experimental and is potentially not very 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:
 
 ```ruby
 class Post < ActiveRecord::Base
@@ -392,18 +395,17 @@ 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
+```ruby
 class Post < ActiveRecord::Base
   include Hoardable::Model # or `Hoardable::Associations` if you don't need `PostVersion`
   has_rich_text :content, hoardable: true
@@ -412,7 +414,7 @@ end
 
 Now the `rich_text_content` relationship will be managed as a Hoardable `has_one` relationship:
 
-``` ruby
+```ruby
 post = Post.create!(content: '<div>Hello World</div>')
 datetime = DateTime.current
 post.update!(content: '<div>Goodbye Cruel World</div>')
@@ -423,64 +425,61 @@ Hoardable.at(datetime) do
 end
 ```
 
-### Known Gotchas
+## Known Gotchas
 
-#### Rails Fixtures
+### Rails Fixtures
 
 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_girl` 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 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.
 
 #### [`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` 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.
 
 #### [`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
 

data/lib/generators/hoardable/functions/hoardable_prevent_update_id.sql

@@ -0,0 +1,8 @@
+CREATE OR REPLACE FUNCTION hoardable_prevent_update_id() RETURNS trigger
+  LANGUAGE plpgsql AS
+$$BEGIN
+  IF NEW.hoardable_id <> OLD.hoardable_id THEN
+    RAISE EXCEPTION 'hoardable id cannot be updated';
+  END IF;
+  RETURN NEW;
+END;$$;

data/lib/generators/hoardable/functions/hoardable_source_set_id.sql

@@ -0,0 +1,18 @@
+CREATE OR REPLACE FUNCTION hoardable_source_set_id() RETURNS trigger
+  LANGUAGE plpgsql AS
+$$
+DECLARE
+  _pk information_schema.constraint_column_usage.column_name%TYPE;
+  _id _pk%TYPE;
+BEGIN
+  SELECT c.column_name
+    FROM information_schema.table_constraints t
+    JOIN information_schema.constraint_column_usage c
+    ON c.constraint_name = t.constraint_name
+    WHERE c.table_name = TG_TABLE_NAME AND t.constraint_type = 'PRIMARY KEY'
+    LIMIT 1
+    INTO _pk;
+  EXECUTE format('SELECT $1.%I', _pk) INTO _id USING NEW;
+  NEW.hoardable_id = _id;
+  RETURN NEW;
+END;$$;

data/lib/generators/hoardable/functions/hoardable_version_prevent_update.sql

@@ -0,0 +1,6 @@
+CREATE OR REPLACE FUNCTION hoardable_version_prevent_update() RETURNS trigger
+  LANGUAGE plpgsql AS
+$$BEGIN
+  RAISE EXCEPTION 'updating a version is not allowed';
+  RETURN NEW;
+END;$$;

data/lib/generators/hoardable/install_generator.rb

@@ -8,6 +8,7 @@ module Hoardable
   class InstallGenerator < Rails::Generators::Base
     source_root File.expand_path('templates', __dir__)
     include Rails::Generators::Migration
+    delegate :supports_schema_enums?, to: :class
 
     def create_initializer_file
       create_file(
@@ -22,12 +23,25 @@ module Hoardable
       )
     end
 
+    def change_schema_format_to_sql
+      return if supports_schema_enums?
+
+      application 'config.active_record.schema_format = :sql'
+    end
+
     def create_migration_file
       migration_template 'install.rb.erb', 'db/migrate/install_hoardable.rb'
     end
 
-    def change_schema_format_to_sql
-      application 'config.active_record.schema_format = :sql'
+    def create_functions
+      Dir.glob(File.join(__dir__, 'functions', '*.sql')).each do |file_path|
+        file_name = file_path.match(%r{([^/]+)\.sql})[1]
+        template file_path, "db/functions/#{file_name}_v01.sql"
+      end
+    end
+
+    def self.supports_schema_enums?
+      ActiveRecord.version >= ::Gem::Version.new('7.0.0')
     end
 
     def self.next_migration_number(dir)

data/lib/generators/hoardable/migration_generator.rb

@@ -9,12 +9,30 @@ module Hoardable
   class MigrationGenerator < ActiveRecord::Generators::Base
     source_root File.expand_path('templates', __dir__)
     include Rails::Generators::Migration
-    class_option :foreign_key_type, type: :string
+    class_option(
+      :foreign_key_type,
+      type: :string,
+      optional: true,
+      desc: 'explictly set / override the foreign key type of the versions table'
+    )
 
     def create_versions_table
       migration_template 'migration.rb.erb', "db/migrate/create_#{singularized_table_name}_versions.rb"
     end
 
+    def create_triggers
+      {
+        versions_prevent_update: singularized_table_name,
+        set_hoardable_id: table_name,
+        prevent_update_hoardable_id: table_name
+      }.each do |(trigger_name, trigger_table_name)|
+        template(
+          "../triggers/#{trigger_name}.sql",
+          "db/triggers/#{trigger_table_name}_#{trigger_name}_v01.sql"
+        )
+      end
+    end
+
     no_tasks do
       def foreign_key_type
         options[:foreign_key_type] ||

data/lib/generators/hoardable/templates/install.rb.erb

@@ -1,65 +1,34 @@
 # frozen_string_literal: true
 
 class InstallHoardable < ActiveRecord::Migration[<%= ActiveRecord::Migration.current_version %>]
-  def up
-    execute(
-      <<~SQL.squish
-        DO $$
-        BEGIN
-          IF NOT EXISTS (
-            SELECT 1 FROM pg_type t WHERE t.typname = 'hoardable_operation'
-          ) THEN
-            CREATE TYPE hoardable_operation AS ENUM ('update', 'delete', 'insert');
-          END IF;
-        END
-        $$;
+  def change
+    create_function :hoardable_prevent_update_id
+    create_function :hoardable_source_set_id
+    create_function :hoardable_version_prevent_update
+    <% if supports_schema_enums? %>
+    create_enum :hoardable_operation, %w[update delete insert]
+    <% else %>
+    reversible do |dir|
+      dir.up do
+        execute(
+          <<~SQL.squish
+            DO $$
+            BEGIN
+              IF NOT EXISTS (
+                SELECT 1 FROM pg_type t WHERE t.typname = 'hoardable_operation'
+              ) THEN
+                CREATE TYPE hoardable_operation AS ENUM ('update', 'delete', 'insert');
+              END IF;
+            END
+            $$;
+          SQL
+        )
+      end
 
-        CREATE OR REPLACE FUNCTION hoardable_source_set_id() RETURNS trigger
-          LANGUAGE plpgsql AS
-        $$
-        DECLARE
-          _pk information_schema.constraint_column_usage.column_name%TYPE;
-          _id _pk%TYPE;
-        BEGIN
-          SELECT c.column_name
-            FROM information_schema.table_constraints t
-            JOIN information_schema.constraint_column_usage c
-            ON c.constraint_name = t.constraint_name
-            WHERE c.table_name = TG_TABLE_NAME AND t.constraint_type = 'PRIMARY KEY'
-            LIMIT 1
-            INTO _pk;
-          EXECUTE format('SELECT $1.%I', _pk) INTO _id USING NEW;
-          NEW.hoardable_id = _id;
-          RETURN NEW;
-        END;$$;
-
-        CREATE OR REPLACE FUNCTION hoardable_prevent_update_id() RETURNS trigger
-          LANGUAGE plpgsql AS
-        $$BEGIN
-          IF NEW.hoardable_id <> OLD.hoardable_id THEN
-            RAISE EXCEPTION 'hoardable id cannot be updated';
-          END IF;
-          RETURN NEW;
-        END;$$;
-
-        CREATE OR REPLACE FUNCTION hoardable_version_prevent_update() RETURNS trigger
-          LANGUAGE plpgsql AS
-        $$BEGIN
-          RAISE EXCEPTION 'updating a version is not allowed';
-          RETURN NEW;
-        END;$$;
-      SQL
-    )
-  end
-
-  def down
-    execute(
-      <<~SQL.squish
-        DROP TYPE IF EXISTS hoardable_operation;
-        DROP FUNCTION IF EXISTS hoardable_version_prevent_update();
-        DROP FUNCTION IF EXISTS hoardable_source_set_id();
-        DROP FUNCTION IF EXISTS hoardable_prevent_update_id();
-      SQL
-    )
+      dir.down do
+        execute('DROP TYPE IF EXISTS hoardable_operation;')
+      end
+    end
+    <% end %>
   end
 end

data/lib/generators/hoardable/templates/migration.rb.erb

@@ -12,34 +12,15 @@ class Create<%= class_name.singularize.delete(':') %>Versions < ActiveRecord::Mi
     end
     reversible do |dir|
       dir.up do
-        execute(
-          <<~SQL
-            UPDATE <%= table_name %> SET hoardable_id = <%= primary_key %>;
-            CREATE TRIGGER <%= singularized_table_name %>_versions_prevent_update
-              BEFORE UPDATE ON <%= singularized_table_name %>_versions FOR EACH ROW
-              EXECUTE PROCEDURE hoardable_version_prevent_update();
-            CREATE TRIGGER <%= table_name %>_set_hoardable_id
-              BEFORE INSERT ON <%= table_name %> FOR EACH ROW
-              EXECUTE PROCEDURE hoardable_source_set_id();
-            CREATE TRIGGER <%= table_name %>_prevent_update_hoardable_id
-              BEFORE UPDATE ON <%= table_name %> FOR EACH ROW
-              EXECUTE PROCEDURE hoardable_prevent_update_id();
-          SQL
-        )
-      end
-      dir.down do
-        execute(
-          <<~SQL
-            DROP TRIGGER <%= singularized_table_name %>_versions_prevent_update
-              ON <%= singularized_table_name %>_versions;
-            DROP TRIGGER <%= table_name %>_set_hoardable_id
-              ON <%= table_name %>;
-            DROP TRIGGER <%= table_name %>_prevent_update_hoardable_id
-              ON <%= table_name %>;
-          SQL
-        )
+        execute('UPDATE <%= table_name %> SET hoardable_id = <%= primary_key %>;')
       end
     end
+    create_trigger(
+      :<%= singularized_table_name %>_versions_prevent_update,
+      on: :<%= singularized_table_name %>_versions
+    )
+    create_trigger :<%= table_name %>_set_hoardable_id, on: :<%= table_name %>
+    create_trigger :<%= table_name %>_prevent_update_hoardable_id, on: :<%= table_name %>
     change_column_null :<%= table_name %>, :hoardable_id, false
     add_index :<%= singularized_table_name %>_versions, :<%= primary_key %>, unique: true
     add_index :<%= singularized_table_name %>_versions, :hoardable_id

data/lib/generators/hoardable/triggers/prevent_update_hoardable_id.sql

@@ -0,0 +1,3 @@
+CREATE TRIGGER <%= table_name %>_prevent_update_hoardable_id
+  BEFORE UPDATE ON <%= table_name %> FOR EACH ROW
+  EXECUTE PROCEDURE hoardable_prevent_update_id();

data/lib/generators/hoardable/triggers/set_hoardable_id.sql

@@ -0,0 +1,3 @@
+CREATE TRIGGER <%= table_name %>_set_hoardable_id
+  BEFORE INSERT ON <%= table_name %> FOR EACH ROW
+  EXECUTE PROCEDURE hoardable_source_set_id();

data/lib/generators/hoardable/triggers/versions_prevent_update.sql

@@ -0,0 +1,3 @@
+CREATE TRIGGER <%= singularized_table_name %>_versions_prevent_update
+  BEFORE UPDATE ON <%= singularized_table_name %>_versions FOR EACH ROW
+  EXECUTE PROCEDURE hoardable_version_prevent_update();

data/lib/hoardable/database_client.rb

@@ -55,7 +55,7 @@ module Hoardable
     end
 
     def source_attributes_without_primary_key
-      source_record.attributes_before_type_cast.without(source_primary_key, *generated_column_names).merge(
+      source_record.attributes.without(source_primary_key, *generated_column_names).merge(
         source_record.class.select(refreshable_column_names).find(source_record.id).slice(refreshable_column_names)
       )
     end

data/lib/hoardable/engine.rb

@@ -4,7 +4,7 @@
 module Hoardable
   # Symbols for use with setting contextual data, when creating versions. See
   # {file:README.md#tracking-contextual-data README} for more.
-  DATA_KEYS = %i[meta whodunit note event_uuid].freeze
+  DATA_KEYS = %i[meta whodunit event_uuid].freeze
 
   # Symbols for use with setting {Hoardable} configuration. See {file:README.md#configuration
   # README} for more.

data/lib/hoardable/scopes.rb

@@ -73,7 +73,7 @@ module Hoardable
     private
 
     def tableoid
-      connection.execute("SELECT oid FROM pg_class WHERE relname = '#{table_name}'")[0]['oid']
+      @tableoid ||= connection.execute("SELECT oid FROM pg_class WHERE relname = '#{table_name}'")[0]['oid']
     end
   end
 end

data/lib/hoardable/version.rb

@@ -1,5 +1,5 @@
 # frozen_string_literal: true
 
 module Hoardable
-  VERSION = '0.12.9'
+  VERSION = '0.14.0'
 end

data/lib/hoardable/version_model.rb

@@ -130,7 +130,7 @@ module Hoardable
     end
 
     def hoardable_source_attributes
-      attributes_before_type_cast.without(
+      attributes.without(
         (self.class.column_names - self.class.superclass.column_names) +
         (SUPPORTS_VIRTUAL_COLUMNS ? self.class.columns.select(&:virtual?).map(&:name) : [])
       )

data/sig/hoardable.rbs

@@ -1,6 +1,6 @@
 module Hoardable
   VERSION: String
-  DATA_KEYS: [:meta, :whodunit, :note, :event_uuid]
+  DATA_KEYS: [:meta, :whodunit, :event_uuid]
   CONFIG_KEYS: [:enabled, :version_updates, :save_trash]
   VERSION_CLASS_SUFFIX: String
   VERSION_TABLE_SUFFIX: String
@@ -57,7 +57,7 @@ module Hoardable
     def source_attributes_without_primary_key: -> untyped
     def initialize_temporal_range: -> Range
     def initialize_hoardable_data: -> untyped
-    def assign_hoardable_context: (:event_uuid | :meta | :note | :whodunit key) -> nil
+    def assign_hoardable_context: (:event_uuid | :meta | :whodunit key) -> nil
     def unset_hoardable_version_and_event_uuid: -> nil
     def previous_temporal_tsrange_end: -> untyped
     def hoardable_source_epoch: -> untyped

metadata

@@ -1,14 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: hoardable
 version: !ruby/object:Gem::Version
-  version: 0.12.9
+  version: 0.14.0
 platform: ruby
 authors:
 - justin talbott
 autorequire:
 bindir: exe
 cert_chain: []
-date: 2022-10-23 00:00:00.000000000 Z
+date: 2023-03-19 00:00:00.000000000 Z
 dependencies:
 - !ruby/object:Gem::Dependency
   name: activerecord
@@ -70,6 +70,26 @@ dependencies:
     - - "<"
       - !ruby/object:Gem::Version
         version: '8'
+- !ruby/object:Gem::Dependency
+  name: fx
+  requirement: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '0.8'
+    - - "<"
+      - !ruby/object:Gem::Version
+        version: '1'
+  type: :runtime
+  prerelease: false
+  version_requirements: !ruby/object:Gem::Requirement
+    requirements:
+    - - ">="
+      - !ruby/object:Gem::Version
+        version: '0.8'
+    - - "<"
+      - !ruby/object:Gem::Version
+        version: '1'
 - !ruby/object:Gem::Dependency
   name: pg
   requirement: !ruby/object:Gem::Requirement
@@ -104,10 +124,16 @@ files:
 - LICENSE.txt
 - README.md
 - Rakefile
+- lib/generators/hoardable/functions/hoardable_prevent_update_id.sql
+- lib/generators/hoardable/functions/hoardable_source_set_id.sql
+- lib/generators/hoardable/functions/hoardable_version_prevent_update.sql
 - lib/generators/hoardable/install_generator.rb
 - lib/generators/hoardable/migration_generator.rb
 - lib/generators/hoardable/templates/install.rb.erb
 - lib/generators/hoardable/templates/migration.rb.erb
+- lib/generators/hoardable/triggers/prevent_update_hoardable_id.sql
+- lib/generators/hoardable/triggers/set_hoardable_id.sql
+- lib/generators/hoardable/triggers/versions_prevent_update.sql
 - lib/hoardable.rb
 - lib/hoardable/associations.rb
 - lib/hoardable/belongs_to.rb
@@ -141,14 +167,14 @@ required_ruby_version: !ruby/object:Gem::Requirement
   requirements:
   - - ">="
     - !ruby/object:Gem::Version
-      version: 2.6.0
+      version: 2.7.0
 required_rubygems_version: !ruby/object:Gem::Requirement
   requirements:
   - - ">="
     - !ruby/object:Gem::Version
       version: '0'
 requirements: []
-rubygems_version: 3.3.7
+rubygems_version: 3.4.6
 signing_key:
 specification_version: 4
 summary: An ActiveRecord extension for versioning and soft-deletion of records in