Cloning Data

A page of content (and remember that pretty much everything in Snap! is a page) can be cloned.

Pages are defined using a URI such as:

/journal/20141019/about-the-snap-trashcan

Cloning allows you to create a duplicate of that page. Maybe you wanted to copy it to:

/favorite/about-the-snap-trashcan

Having a copy would allow you to not lose the previous version and new edits on either one do not affect the other. This could also be used when writing a book and a page is quite similar (i.e. the copyright page.)

The clone process copies all the data in the pages, data included in the content, branch, and revision tables. It also allows any plugin interested to verify the data. For example, the links plugin needs to fix the links so they all point to the new page.

Moving Data

The cloning process is also used in another situation: when moving data from one place to another. Although it may sound very simple to have some form of inode and moving (as in renaming) could be done just by changing the URI of the inode, it is not exactly that simple in an environment where URIs appear in fields.

Indeed, if a book has many pages and the author created a reference from page A to page B, that reference would break whenever the pages are given a new URI. Although you may think that it would be easy to just use the inode number for those pages, the truth is that people who handle HTML would have no clue what inodes are and as a client user, you would not even know what these are. That means a heavy duty on the server to parse all the data being saved at the time it gets saved to transform any URI to an inode. So it is not that simple.

Using the clone feature as a move solves the issue by allowing a backend to check the data at its leisure and fix any URI that go to a deleted (hidden) page and change them to the new page. That also works in realtime: if a user attempts to access page A when it was moved to page B, he can be redirected to page B automatically. This is quite important as some system, most particularly search engines, may have cached the URI of page A and telling them that now they have to use page B's URI instead could not be done if page A's tracks were immediately erased.

Trashcan Functionality

As a side effect of the moving capability, we implemented the trashcan. Internally, this feature is called "content delete". It will move the content specified at the given path to the trashcan. It will stay there for the time specified by the administrator.

At this point pages cannot just be destroyed, only moved to the trashcan. There are technical reasons for which we want to do so: data being deleted in a Cassandra cluster may get resurected if a node was down while executing the deletion. To prevent a page from coming back from the dead, we need to have a long deletion procedure to make it safe. (see Why using a Trashcan?)

Of course, another reason to have a trashcan is to allow the end users to restore things he deleted and afterward decided it should not have been deleted.

Current Implementation Status

At this point the low level functions are implemented and work perfectly. There is, however, absolutely no interface to make use of them as an end user. Until then, the feature will be marked as "Alpha Version."