When you update an InterMine production database, user lists have to be updated as well. This document aims to describe this process.
Lists are saved in the userprofile savedbag, bagvalues tables and in the production database osbag_int table.
|bagid||unique bag id|
|value||intermine object id|
The InterMine ID is only valid per database. If the database is rebuilt, the IDs change and the information in this table becomes incorrect. The lists require an upgrade for them to be updated with the new, correct InterMine object IDs.
|type||type of object, eg. Gene|
|name||name of list, provided by user|
|description||description, provided by user|
|intermine_state||CURRENT, NOT_CURRENT or TO_UPGRADE|
|value||identifier originally typed in by user|
|extra||organism short name|
Lists are saved along with the user information in the savedbag table. The identifiers used to create a list are also stored in the bagvalues table in the userprofile database. These identifiers are used to upgrade the list to internal object ids in the new production database.
To make queries fast, the list contents are stored in the production database as internal object ids. When a new production database is used, the object ids are no longer valid and need to be “upgraded”.
If a list is not current:
The list upgrade system, needs a bagvalues table in the userprofile database, with savedbagid and value columns. This table should be generated manually, running the load-bagvalues-table ant task in the webapp directory. The load-bagvalues-table task, should create the table and load the contents of the list using the former production db, that is the same db used to create the saved lists. Every time, you re-create the userprofile database, you have to re-generate the ‘bagvalues’ table. In theory, you should never re-create the userprofile db, so you should run the load-bagvalues-table task only once.
The table should be populated with one row corresponding to each row in production db osbag_int table. Each row should contain the IntermineBag id and the first value not empty of the primary identifier field, defined in the class_keys properties file.
The bagvalues table is updated when the user is logged in and:
When a user logs in, any lists he has created in his session become saved bags in the userprofile database, and the bagvalues table should be updated as well. The contents of bagvalues is only needed when upgrading to a new release. The thread upgrading the lists, uses the contents of bagvalues as input and, if the list upgrades with no issues:
The intermine-current in the table savedbag marks whether the bag has been upgraded. The column is generated when you create the userprofile database or when load-bagvalues-table has been executed.
The list upgrade functionality uses a serialNumber that identifies the production database. The serialNumber is re-generated each time we build a new production db. On startup of the webapp, the webapp compares the production serialNumber with its own serialNumber (before stored using the production serialNumber). If the two serialNumbers match, the lists will not be updgraded; if don’t, the lists are set as ‘not current’ and will be upgraded only when the user logs in.
There are four cases:
- Scenario: I have released the webapp but I haven’t re-build the production db.
- Scenario: I have run build-db in the production db and it’s the first time that I release the webapp. On startup, the webapp sets intermine_current to false and the userprofile serialNumber value with the production serialNumber value.
- Scenario: we have released the webapp but we haven’t changed the production db.
- Scenario: we have run build-db in the production and a new serialNumber has been generated.
The following diagram shows the possible states. With the green, we identify the states that don’t need a list upgrade, with the red those need a list upgrade.