Client Storage

The Weave server can store information on behalf of the user, for example, the bookmarks that a user saves. This information is stored on the server so that when the user begins a new session it is available for access.

Previously this information was stored using an API provided by the OSGi framework that Weave is built upon. This implementation was file-based with the content stored under the platform\configuration directory. The OSGi API appeared to have issues with performance and corruption when used under load, plus the settings would be lost if the configuration directory was cleaned out (which is sometimes required).

To overcome the issues with the OSGi implementation it was replaced by another implementation that uses a database to store the information. By default, the database used is the 'system' database, which is a local HSQLDB database created and managed by Weave for use when the Weave server itself requires a database for internal activities. The content for the system database is stored in the platform\workspace\.storage directory.

Alternatively, the storage database can be switched to any data source configured within Weave, with support for Oracle, SQL Server, DB2, Postgres and SQLite.

The reason this is limited to those databases (plus HSQLDB) is that the database storage implementation will create the tables and indexes as required if they do not already exist, and since this process varies depending upon the underlying database, different SQL must be generated and used for each database type (which is different from the rest of Weave which attempts to use generic SQL that can be used on any database, and not just those four).

To change the storage database to a different data source the Java system property storage.datasource should be set to provide the id of a data source registered within Weave. In a standard Weave installation, this can be done in theby adding a new line to the ...\jetty_base\start.d\weave.ini file. Other installations may have other methods to set system properties. If the storage.datasource property isn't specified then Weave will use the value "system.datasource", which is the id of the internal HSQLDB database.

weave.ini line to change storage database, assumes a Weave datasource with the id 'ds.sqlserver'

-Dstorage.datasource=ds.sqlserver

The older OSGi implementation and the newer database implementation both support using the ustorage command at the osgi prompt to import/export the data they contain.

This allows migration from the older implementation to the newer, or from the newer database implementation that uses the internal system database to an external database.

So to ensure your users settings are not lost you should execute the 'ustorage save' command before setting the storage.datasource value, then 'ustorage load' after setting it. This will ensure that previous values are migrated to the new database.

Note that if your organisation changes a userid, or changes all users userid's, it will break the link between the user and the information stored for that user in Weave, since all the information stored for an individual user is linked to their userid.

Currently, the only way to rectify this is to use the ustorage save command, edit the exported file by hand to change the userid's and then use ustorage load to re-load the updated content.

Manually Creating Tables

These tables will be created automatically by Weave the first time it tries to access them. The following information is provided for informational purposes or, if for some reason, you need to create the tables manually.

SQL Server

CREATE TABLE wv_user_nodes(id INT IDENTITY(1,1) NOT NULL, parentid INT NOT NULL, name NVARCHAR(50) NOT NULL, CONSTRAINT wv_user_nodes_PK PRIMARY KEY(id))

CREATE TABLE wv_user_attributes(id INT NOT NULL, name NVARCHAR(50) NOT NULL, value VARBINARY(MAX) NOT NULL, CONSTRAINT wv_user_attributes_PK PRIMARY KEY (id, name))

Oracle

CREATE TABLE wv_user_nodes(id INTEGER PRIMARY KEY, parentid INTEGER NOT NULL, name VARCHAR(50) NOT NULL)

CREATE TABLE wv_user_attributes(id INTEGER NOT NULL, name VARCHAR(50) NOT NULL, value BLOB NOT NULL, CONSTRAINT wv_user_attributes_PK PRIMARY KEY (id, name))

CREATE SEQUENCE wv_user_nodes_SQ

DB2

CREATE TABLE wv_user_nodes(id INTEGER GENERATED ALWAYS AS IDENTITY PRIMARY KEY, parentid INTEGER NOT NULL, name VARCHAR(50) NOT NULL)

CREATE TABLE wv_user_attributes(id INTEGER NOT NULL, name VARCHAR(50) NOT NULL, value BLOB NOT NULL, PRIMARY KEY (id, name))

Postgres

CREATE TABLE wv_user_nodes(id SERIAL, parentid INTEGER NOT NULL, name VARCHAR(50) NOT NULL, PRIMARY KEY(id))

CREATE TABLE wv_user_attributes(id INTEGER NOT NULL, name VARCHAR(50) NOT NULL, value BYTEA NOT NULL, PRIMARY KEY (id, name))

HSQLDB

CREATE CACHED TABLE wv_user_nodes(id INTEGER GENERATED ALWAYS AS IDENTITY PRIMARY KEY, parentid INTEGER NOT NULL, name VARCHAR(50) NOT NULL)

CREATE CACHED TABLE wv_user_attributes(id INTEGER NOT NULL, name VARCHAR(50) NOT NULL, value OTHER NOT NULL, PRIMARY KEY (id, name))

SQLite

CREATE TABLE wv_user_nodes(id INTEGER PRIMARY KEY AUTOINCREMENT, parentid INTEGER NOT NULL, name VARCHAR(50) NOT NULL)

CREATE TABLE wv_user_attributes(id INTEGER NOT NULL, name TEXT NOT NULL, value BLOB NOT NULL, PRIMARY KEY (id, name))