[QUESTION] Implementing version history with cloure_tree.

[rvega]

Hi, I already posted this question at http://stackoverflow.com/questions/13457479/implementing-version-history-with-a-closure-table-schema but I thought I should get mceachen's attention on it:

I have a custom CMS implementation that stores content nodes using the closure_tree gem.

The time has come for me to implement a version history where any change in the content tree (editing, inserting, moving, deleting nodes, etc.) would create a new version of the root node (a publication). And users would be able to look at older versions and revert back to them. The revert action would create a newer version which is a copy of the reverted one.

Is there a well known way to achieve this? or does anyone have an idea or example implementation for this sort of thing?

Thanks!

[mceachen]

I don't understand your model well enough to know what you're asking. Why
is the content itself in a hierarchy? Is it representative of what links
where?

Generally speaking, to show version control hierarchies like git, you'd
need to support arbitrary numbers of parents. That isn't supported by this
gem (at least currently). If your version history is more linear (no
concurrent edits and no need for merging), a simple linked list would work.

Matthew

On Nov 19, 2012, at 8:03 AM, Rafael Vega [email protected] wrote:

Hi, I already posted this question at
http://stackoverflow.com/questions/13457479/implementing-version-history-with-a-closure-table-schemabut
I thought I should get mceachen's attention on it:

I have a custom CMS implementation that stores content nodes using the
closure_tree gem.

The time has come for me to implement a version history where any change in
the content tree (editing, inserting, moving, deleting nodes, etc.) would
create a new version of the root node (a publication). And users would be
able to look at older versions and revert back to them. The revert action
would create a newer version which is a copy of the reverted one.

Is there a well known way to achieve this? or does anyone have an idea or
example implementation for this sort of thing?

Thanks!

—
Reply to this email directly or view it on
GitHubhttps://github.com//issues/27.

[vjt]

Hi @rvega,

you may have a look at chronomodel, a Slowly-Changing Dimension implementation for PostgreSQL. I'm using it in combination with Closure Tree, and except for #29 it works perfectly.

Ciao,

~Marcello

[rvega]

@vjt Thanks, I will take a look at it!
:)

[vjt]

You're welcome :-)

To be honest, by the way, ChronoModel doesn't work on the _hierarchy table, as it doesn't have a primary key - but I'm cooking a workaround right now using OIDs. As long as you are not interested in keeping the history of the tree structure itself but rather only the history of the referenced nodes, you'd be fine right now.

Let me know on the ChronoModel project itself - as I think that I've already spammed this project enough ;-)

[vjt]

@rvega ChronoModel now works with closure_tree's _hierarchy table 😄

Quick demonstration:

[34] pry(main)> a.reload.children
  Address Load (0.6ms)  SELECT "addresses".* FROM "addresses" WHERE "addresses"."id" = $1 LIMIT 1  [["id", 20523]]
  Address Load (7.9ms)  SELECT "addresses".* FROM "addresses" WHERE "addresses"."parent_id" = 20523 ORDER BY name
+-------+-----------+-------------+-----------+---------+---------+-----------+-------+-------------+--------+----------+-------+-----+-----------+---------+------------+-----------+
| id    | entity_id | entity_type | parent_id | city_id | type_id | name      | title | description | street | province | pobox | zip | zip_after | remarks | use_for_va | legacy_id |
+-------+-----------+-------------+-----------+---------+---------+-----------+-------+-------------+--------+----------+-------+-----+-----------+---------+------------+-----------+
| 20525 | 122       | Country     | 20523     | 8334625 | 1       | FooBarBaz |       |             |        |          |       |     |           |         | false      | 43094933  |
+-------+-----------+-------------+-----------+---------+---------+-----------+-------+-------------+--------+----------+-------+-----+-----------+---------+------------+-----------+
1 row in set
[35] pry(main)> a.as_of(30.minutes.ago).children
  Address Load (70.0ms)  WITH addresses AS (SELECT "history"."addresses".*, '2012-11-30 18:56:01.179124' AS as_of_time FROM "history"."addresses" WHERE ('2012-11-30 18:56:01.179124' >= "history"."addresses"."valid_from" AND '2012-11-30 18:56:01.179124' < "history"."addresses"."valid_to")) SELECT "addresses".* FROM "addresses" WHERE "addresses"."id" = 20523 LIMIT 1
  Address Load (71.4ms)  WITH addresses AS (SELECT "history"."addresses".*, '2012-11-30 18:56:01.179124' AS as_of_time FROM "history"."addresses" WHERE ('2012-11-30 18:56:01.179124' >= "history"."addresses"."valid_from" AND '2012-11-30 18:56:01.179124' < "history"."addresses"."valid_to")) SELECT "addresses".* FROM "addresses" WHERE "addresses"."parent_id" = 20523 ORDER BY name
+-------+---------+---------+---------+---------+---------+---------+-------+---------+--------+---------+-------+-----+----------+---------+---------+---------+-------+----------+----------+---------+---------+
| id    | enti... | enti... | pare... | city_id | type_id | name    | title | desc... | street | prov... | pobox | zip | zip_a... | remarks | use_... | lega... | hid   | valid... | valid_to | reco... | as_o... |
+-------+---------+---------+---------+---------+---------+---------+-------+---------+--------+---------+-------+-----+----------+---------+---------+---------+-------+----------+----------+---------+---------+
| 20525 | 122     | Country | 20523   | 8334625 | 1       | FooB... |       |         |        |         |       |     |          |         | false   | 4309... | 20519 | 2012-... | 9999-... | 2012... | 2012... |
| 20526 | 122     | Country | 20523   |         | 1       | ldlsls  |       |         |        |         |       |     |          |         | false   | 2131334 | 20552 | 2012-... | 2012-... | 2012... | 2012... |
+-------+---------+---------+---------+---------+---------+---------+-------+---------+--------+---------+-------+-----+----------+---------+---------+---------+-------+----------+----------+---------+---------+

[mceachen]

@vjt nice! Closing.