hoardable 0.1.4 → 0.2.0
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- checksums.yaml +4 -4
- data/README.md +50 -8
- data/lib/hoardable/version.rb +1 -1
- metadata +2 -2
checksums.yaml
CHANGED
@@ -1,7 +1,7 @@
|
|
1
1
|
---
|
2
2
|
SHA256:
|
3
|
-
metadata.gz:
|
4
|
-
data.tar.gz:
|
3
|
+
metadata.gz: c960d95a373942d9183464cc50b7c4213c25c7563fa9d920c81d2c325ea71705
|
4
|
+
data.tar.gz: e7e0f289e60acd720538edc15584209ed3d30e08b21758d06884a5486f198ee0
|
5
5
|
SHA512:
|
6
|
-
metadata.gz:
|
7
|
-
data.tar.gz:
|
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
|
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
|
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
|
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
|
|
data/lib/hoardable/version.rb
CHANGED
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.
|
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-
|
11
|
+
date: 2022-08-08 00:00:00.000000000 Z
|
12
12
|
dependencies:
|
13
13
|
- !ruby/object:Gem::Dependency
|
14
14
|
name: activerecord
|