Skip to content

Create new af-specific db

davidnoirman requested to merge issue/82/shadow-version into master

Creates a db where occupation-name, ssyk-level-4 and occupation-field concepts are changed to their version 1 states (in regards to labels, deprecated status and ssyk relations). The version includes only new occupation-name concepts.

A data rollback to its pre shadow version state is then performed, after which a new version must be deployed.

So: version1+newconcepts

See #82 (closed)

How to

  1. download copy of prod-write-db
  2. set up a local api towards the db

When performing the first transaction below, make sure the note the :t value for :db-after in the REPL output.

Run the transact-changes function 7 times (in total) with the following arguments:

  1. (map label-reverter (find-updates v-1-occupations v-next-occupations))
  2. (resurrector (find-deprecated (keys (ids-and-labels v-1-occupations)) v-next-occupations))
  3. (map retract-relation (find-updates v-1-occupations v-next-occupations true))
  4. (map reconnect-relation (find-updates v-1-occupations v-next-occupations true))
  5. (map label-reverter (find-updates (get-broader-concepts v-1-ssyk-and-field) (get-broader-concepts v-next-ssyk-and-field)))
  6. (map retract-relation (find-updates v-1-ssyk-and-field v-next-ssyk-and-field true))
  7. (map reconnect-relation (find-updates v-1-ssyk-and-field v-next-ssyk-and-field true))
  8. (retract-replaced-by)

Verify that the changes have been transacted. Then create a new version. This is the shadow version. The shadow version must be hidden between two actual ones. So the changes we just performed will have to be reversed in order to get a new version, but in its pre shadow state.

The rollback function will be used to revert all changes between two specified transactions. The rollback function takes a log from the get-tx-log function.

The :start-value we will specify in the get-tx-log function is the one we noted when we did our first transaction.

When our shadow version was created its transaction-value became the latest. We do not want to include it in our data rollback. Thus the :t-value of the version transaction needs to be supplied as the :end-parameter in the get-tx-log function.

Then map the rollback function to the tx-log collection.

Then reload the REPL and test to see if that version is comparable to "next" version before creating a new one. The current ("next") version should be the same as the one before the shadow version apart from any newly created occupations.

Create new version and deploy the database.

Edited by davidnoirman

Merge request reports