First, let me clarify the semantics of the snapshots with a simple example. Consider the database tables (Snapshot, Snapshot_User and User) below.

As you can see, the user identified by id==2 ('tester') is referenced by both snapshots. If someone modifies the password of 'tester' - e.g. the administrator resets it - it should take effect only within snapshot HEAD. Thus, the entity must be copied while maintaining its relationships to the Role table:

We would see a similar effect if 'tester' is assigned another role (instead of or in addition to changing its password).

[Top]

Next we consider a more complex scenario additionally involving a role entity:

The role identified by id==2 ('appuser') is referenced by both snapshots. In fact all of the roles are referenced by both snapshots at present but we concentrate on the 'appuser' role and the users which own this role. Again user 'tester' is referenced by both snapshots whereas 'supertester' identified by id==3 is referenced only from snapshot HEAD (blue lines). The tables below visualize the relationships between users and roles:

Both user 'tester' and 'supertester' (id==3) are owning the role 'appuser' with id==2. A former snapshot of 'supertester' (id==1) is owning this role as well but any changes can't affect entities referenced by past snapshots. Hence we concentrate on the users with id==2 and id==3. What is the correct behaviour if someone changes the meaning of role 'appuser'? Does this change the states of the affected users as well? We define that variations of roles do affect the state of the involved users but not vice versa. That is to say, the application logic focuses on the 'fulfills' relationship between the User and Role entities but not on the inverse 'owned by' relationship.

Hence, if someone modifies the 'appuser' role the outcome is as follows:

Another (changed) incarnation of the role 'appuser' has emerged (id==10) and is referenced by snapshot HEAD. The old one is still reachable by the former snapshot. Since user 'tester' had been referenced by both snapshots and the modified role affected him, we see another user 'tester' as well. The user 'supertester' (id==3) needn't to be copied because he was exclusively owned by HEAD. Now look at the tables below which visualize the updated relationships between the User and Role entities.

The old incarantion of 'tester' (id==2) still fulfills the unchanged 'appuser' role (id==2) whereas the new incarnation owns the altered 'appuser' role.

It is possible to scroll through the various snapshots by clicking on a (AJAX) spinner control of the web frontend. All of the other controls will then be updated depending on the chosen snapshot. The RBAC distribution provides a SQL query which joins all entities and their relationships together with the corresponding snapshots. This query can be used to get an overview of the chronological order when experimenting with the snapshots.

[Top]