Component Implementation - Lesson 7 - Data Repository

As mentioned above, if we use MDRepositoryBeanWithStatistics as our base class for TestRepositoryMDBean, then we may have different data sources used for different domains. By default, if we will not configure it otherwise, MDRepositoryBeanWithStatistics will create only single repository instance named default. It will be used for all domains and it will, by default, use data source named the same as repository instance - it will use data source named default. This defaults are equal to following configuration entered in the config file:

test(class: TestComponent) {
    repository () {
        default () {
            dataSourceName = 'default'
        }
    }
}

It is possible to make any repository use different data source than data source configured under the same name as repository instance. To do so, you need to set dataSourceName property of repository instance to the name of data source which it should use.

Example setting repository default to use data source named test. 

test(class: TestComponent) {
    repository () {
        default () {
            dataSourceName = 'test'
        }
    }
}

To configure repository instance to be used for particular domain, you need to define repository with the same name as domain for which it should be used. It will, by default, use data source with name equal domain name.

Separate repository for example.com using data source named example.com. 

dataSource () {
    // configuration of data sources here is not complete
    default () {
        uri = "jdbc:derby:/database"
    }
    'example.com' () {
        uri = "jdbc:derby/example"
    }
}

test(class: TestComponent) {
    repository () {
        default () {
        }
        'example.com' () {
        }
    }
}

Separate repository for example.com using data source named test. 

dataSource () {
    // configuration of data sources here is not complete
    default () {
        uri = "jdbc:derby:/database"
    }
    'test' () {
        uri = "jdbc:derby/example"
    }
}

test(class: TestComponent) {
    repository () {
        default () {
        }
        'example.com' () {
            dataSourceName = 'test'
        }
    }
}

First of all, repository implementation should implement tigase.db.util.RepositoryVersionAware interface (all it’s methods are defined by default) and annotate it with tigase.db.Repository.SchemaId. For example .Repository annoted with SchemaId and implementing RepositoryVersionAware

@Repository.SchemaId(id = "test-component", name = "Test Component")
public static class TestRepositoryMDBean extends MDRepositoryBeanWithStatistics<TestRepositoryIfc>
    implements TestRepositoryIfc {
…
}

This action alone will result in performing the check during Tigase XMPP Server startup and initialisation of repository whether tables, indexes, stored procedures and other elements are present in the configured data source in the required version. By default, required version matches the implementation version (obtained via call to java.lang.Package.getImplementationVersion()), however it’s possible to specify required version manually, either:

@Repository.SchemaId(id = "test_component", name = "Test Component")
@RepositoryVersionAware.SchemaVersion(version = "0.0.1")
public static class TestRepositoryMDBean extends MDRepositoryBeanWithStatistics<TestRepositoryIfc>
    implements TestRepositoryIfc {
…
}

	@Override
	public Version getVersion() {
		return "0.0.1";
	}

To detect that version information in database is inadequate following logic will take place:

Upgrade of the loaded schema in the database will be performed by executing:

./scripts/tigase.sh upgrade-schema etc/tigase.conf

The above command will load current configuration, information about all configured data sources and enabled components, and then perform upgrade of the schema of each configured component in the appropriate data source.

Depending on the type of the database (or specified annotation), how the upgrade procedure is handled internally is slightly different.

@Repository.SchemaId(id = "test_component", name = "Test Component", external = false)

Each versioned schema file should consist at the end code responsible for setting appropriate version of the loaded schema in the form of Stored Procedure call with the name of the component and the version as parameters:

-- QUERY START:
select TigSetComponentVersion('test_component', '0.0.5');
-- QUERY END:

-- QUERY START:
exec TigSetComponentVersion 'test_component', '0.0.5';
-- QUERY END:
GO

-- QUERY START:
call TigSetComponentVersion('test_component', '0.0.5');
-- QUERY END:

-- QUERY START:
call TigSetComponentVersion('test_component', '0.0.5');
-- QUERY END:

In case of schema handled internally, after successful load (i.e. execution of the implemented tigase.db.util.RepositoryVersionAware.updateSchema method returning tigase.db.util.SchemaLoader.Result.ok) the version in the database will be set to the current version of the component.

This allows (in case of schema handled externally) to load it by hand by directly importing .sql files into database.