hoardable 0.1.4 → 0.2.0

Sign up to get free protection for your applications and to get access to all the features.
Files changed (4) hide show
  1. checksums.yaml +4 -4
  2. data/README.md +50 -8
  3. data/lib/hoardable/version.rb +1 -1
  4. metadata +2 -2
checksums.yaml CHANGED
@@ -1,7 +1,7 @@
1
1
  ---
2
2
  SHA256:
3
- metadata.gz: a5e5c29b0b6d4a24e7b41a9b4846fd1288caabd48158b517a4b9b61e53421d1c
4
- data.tar.gz: 1e863147db8e3a39e4ed3d465855d465f14c4c8a444426abce72534e8bae4d9c
3
+ metadata.gz: c960d95a373942d9183464cc50b7c4213c25c7563fa9d920c81d2c325ea71705
4
+ data.tar.gz: e7e0f289e60acd720538edc15584209ed3d30e08b21758d06884a5486f198ee0
5
5
  SHA512:
6
- metadata.gz: 4c997b34958fbe6253098778c03bf9226eac02b7fd218af1a1d1bd52527b7b1a0b0406a6ecf0cc8e3ea45d70e5b8823dc23a0e48fcc741c470831b98adb3fd65
7
- data.tar.gz: 44b9c1cfe68aa6ab18370b90632d5563dda8ef50b0cde425be3b44eb7f2027fa6e61d609538653cc15adab20f9d79ba3423f614d95c9413f8db4c0ced3a2f4be
6
+ metadata.gz: a83966223151922d24bb009ac50465723388ba91825e27cf933bb5e00370c270a0518ec828358f1109a040e2a9202cee7b37d7ea98e0387b30dc07a74f7eb851
7
+ data.tar.gz: 6bc246f6664b61c5000ffa71b24c8ddd30c409eda87e790b0ea1bd9d47f46c4e85e0b5eb89736939a75018e272cdd5ac2ce1217c7c7e9272ddc4f96cc8cc33f4
data/README.md CHANGED
@@ -3,10 +3,6 @@
3
3
  Hoardable is an ActiveRecord extension for Ruby 2.6+, Rails 6.1+, and PostgreSQL that allows for
4
4
  versioning and soft-deletion of records through the use of _uni-temporal inherited tables_.
5
5
 
6
- [👉 Documentation](https://www.rubydoc.info/gems/hoardable)
7
-
8
- ### huh?
9
-
10
6
  [Temporal tables](https://en.wikipedia.org/wiki/Temporal_database) are a database design pattern
11
7
  where each row of a table contains data along with one or more time ranges. In the case of this gem,
12
8
  each database row has a time range that represents the row’s valid time range - hence
@@ -20,8 +16,10 @@ change is reflected on its descendants.
20
16
  With these concepts combined, `hoardable` offers a simple and effective model versioning system for
21
17
  Rails. Versions of records are stored in separate, inherited tables along with their valid time
22
18
  ranges and contextual data. Compared to other Rails-oriented versioning systems, this gem strives to
23
- be more explicit and obvious on the lower RDBS level while still familiar and convenient within Ruby
24
- on Rails.
19
+ be more explicit and obvious on the lower RDBS level while still familiar and convenient to use
20
+ within Ruby on Rails.
21
+
22
+ [👉 Documentation](https://www.rubydoc.info/gems/hoardable)
25
23
 
26
24
  ## Installation
27
25
 
@@ -119,6 +117,10 @@ post.at(1.day.ago) # => #<PostVersion:0x000000010d44fa30>
119
117
  PostVersion.at(1.day.ago).find_by(post_id: post.id) # => #<PostVersion:0x000000010d44fa30>
120
118
  ```
121
119
 
120
+ _Note:_ A `Version` is not created upon initial parent model creation. If you would like to
121
+ accurately capture the valid temporal frame of the first version, make sure your model’s table has a
122
+ `created_at` timestamp field.
123
+
122
124
  By default, `hoardable` will keep copies of records you have destroyed. You can query for them as
123
125
  well:
124
126
 
@@ -129,7 +131,7 @@ PostVersion.trashed
129
131
  _Note:_ Creating an inherited table does not copy over the indexes from the parent table. If you
130
132
  need to query versions often, you should add appropriate indexes to the `_versions` tables.
131
133
 
132
- ### Tracking contextual data
134
+ ### Tracking Contextual Data
133
135
 
134
136
  You’ll often want to track contextual data about the creation of a version. There are 3 optional
135
137
  symbol keys that are provided for tracking contextual information:
@@ -293,9 +295,49 @@ class Post < ActiveRecord::Base
293
295
  end
294
296
  ```
295
297
 
298
+ ## Gem Comparison
299
+
300
+ ### [`paper_trail`](https://github.com/paper-trail-gem/paper_trail)
301
+
302
+ `paper_trail` is maybe the most popular and fully featured gem in this space. It works for other
303
+ database types than PostgeSQL and (by default) stores all versions of all versioned models in a
304
+ single `versions` table. It stores changes in a `text`, `json`, or `jsonb` column. In order to
305
+ efficiently query the `versions` table, a `jsonb` column should be used, which takes up a lot of
306
+ space to index. Unless you customize your configuration, all `versions` for all models types are
307
+ in the same table which is inefficient if you are only interested in querying versions of a single
308
+ model. By contrast, `hoardable` stores versions in smaller, isolated and inherited tables with the
309
+ same database columns as their parents, which are more efficient for querying as well as auditing
310
+ for truncating and dropping. The concept of a `temporal` time-frame does not exist for a single
311
+ version since there is only a `created_at` timestamp.
312
+
313
+ ### [`audited`](https://github.com/collectiveidea/audited)
314
+
315
+ `audited` works in a similar manner as `paper_trail`. It stores all versions for all model types in
316
+ a single table, you must opt into using `jsonb` as the column type to store "changes", in case you
317
+ want to query them, and there is no concept of a `temporal` time-frame for a single version. It
318
+ makes opinionated decisions about contextual data requirements and stores them as top level data
319
+ types on the `audited` table.
320
+
321
+ ### [`discard`](https://github.com/jhawthorn/discard)
322
+
323
+ `discard` only covers soft-deletion. The act of "soft deleting" a record is only captured through
324
+ the time-stamping of a `discarded_at` column on the records table; there is no other capturing of
325
+ the event that caused the soft deletion unless you implement it yourself. Once the "discarded"
326
+ record is restored, the previous "discarded" awareness is lost. Since "discarded" records exist in
327
+ the same table as "undiscarded" records, you must explicitly omit the discarded records from queries
328
+ across your app to keep them from leaking in.
329
+
330
+ ### [`paranoia`](https://github.com/rubysherpas/paranoia)
331
+
332
+ `paranoia` also only covers soft-deletion. In their README, they recommend using `discard` instead
333
+ of `paranoia` because of the fact they override ActiveRecord’s `delete` and `destroy` methods.
334
+ `hoardable` employs callbacks to create trashed versions instead of overriding methods. Otherwise,
335
+ `paranoia` works similarly to `discard` in that it keeps deleted records in the same table and tags
336
+ them with a `deleted_at` timestamp. No other information about the soft-deletion event is stored.
337
+
296
338
  ## Contributing
297
339
 
298
- This gem is currently considered alpha and very open to feedback.
340
+ This gem still quite new and very open to feedback.
299
341
 
300
342
  Bug reports and pull requests are welcome on GitHub at https://github.com/waymondo/hoardable.
301
343
 
@@ -1,5 +1,5 @@
1
1
  # frozen_string_literal: true
2
2
 
3
3
  module Hoardable
4
- VERSION = '0.1.4'
4
+ VERSION = '0.2.0'
5
5
  end
metadata CHANGED
@@ -1,14 +1,14 @@
1
1
  --- !ruby/object:Gem::Specification
2
2
  name: hoardable
3
3
  version: !ruby/object:Gem::Version
4
- version: 0.1.4
4
+ version: 0.2.0
5
5
  platform: ruby
6
6
  authors:
7
7
  - justin talbott
8
8
  autorequire:
9
9
  bindir: exe
10
10
  cert_chain: []
11
- date: 2022-08-03 00:00:00.000000000 Z
11
+ date: 2022-08-08 00:00:00.000000000 Z
12
12
  dependencies:
13
13
  - !ruby/object:Gem::Dependency
14
14
  name: activerecord