hoardable 0.1.4 → 0.2.0
Sign up to get free protection for your applications and to get access to all the features.
- 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
|