このコンテンツは選択した言語では利用できません。

3.2. Changes to the Hierarchical Database System

APIs

For both releases 5 and 6, client applications use the standard JCR 2.0 API to interact with repositories. So most (if not all) of your application code can remain unchanged.

A small API (org.modeshape.jcr.api) was provided in release 5 that extended the standard JCR API with a few additional capabilities. This release supports and slightly expands on this API. Several of the methods and interfaces in the API were deprecated in the previous release. These have now been removed.

The URLs for the RESTful API have changed. This release provides an improved RESTful API which is now the default. The RESTful client library is compatible with the database system provided in both versions 5 and 6.

The WebDAV API has been improved and the JDBC driver is also still supported.

Caching

In release 5, a single Service Provider Interface (SPI) was used for both storage and access connectors. However, this has been changed as part of a move to a more scalable caching solution.

In this release, each repository uses a single cache for both its caching and storage system. All workspace content (except for binary value storage) and system content is stored within this single cache.

Federation

In this release, the JCR API can be used to access information in external systems. The concept of a connector has been reintroduced as a mechanism to achieve this. Repositories will no longer consist entirely of federated content. Instead, every repository will store its own content, but you will be able to federate and integrate content from external systems into the repository.

Note

Technically, even in the previous release a storage connector was required to store the repository's system content, so it was never actually possible to have a repository that consisted entirely of federated content.

Binary Storage

Repositories can now handle extremely large binary values with several storage options:

Binary values can be stored on the local file system. This can be a regular directory, a network share or even a temporary directory. This option is generally fast, safe (as safe as your file system), and native locks are used to prevent multiple processes from conflicting. It is recommended for local (non-clustered), embedded repositories.
Binary values can be stored in cache. Although it is possible to use the same cache as the rest of the repository, it is often better to use two other caches and to configure those caches specifically for what they store. For example, one cache is used to store metadata about the binary values; this metadata is small, lightweight, and can thus be replicated across the cluster. The other cache is used to store the actual binary data, separated into chunks (usually up to 1MB in size), and for this type of cache, distributing the data across the cluster is often desirable.
Binary values can be stored in a relational database. This is recommended only when you intend to persist all content inside a relational database. The binary data is broken into chunks (usually up to 1MB in size).
Binary values can be stored in MongoDB. This storage option has not been thoroughly tested, but can be considered as an option.
Binary values can be stored in a custom store. A Service Provider Interface (SPI) is now provided for implementing your own binary storage.

Sequencers

Each repository is now configured with its own sequencers. Implementing custom sequencers is simpler since sequencers generate additional content by using the JCR API directly, rather than the proprietary graph API used in the previous release. Sequencer implementations are also able to register the node types programmatically, which simplifies the overall configuration for a repository.

MIME Type Detection

There are two additional methods to the org.modeshape.jcr.api.Binary interface to obtain the MIME type. Your applications can use these methods to discover the MIME type for a binary value and, for example, to set the "jcr:mimeType" property on the node.

The Service Provider Interface (SPI) for custom MIME type detectors has been removed. Instead, the Apache Tika framework is used, which has several MIME type detectors and provides its own SPI for custom detectors.

Text Extractors

A simple Service Provider Interface (SPI) has been added for simple creation of custom extractors.

Configuration

In this release, there is one JSON (previously XML) configuration file for each repository, each "deployed" to an engine. As a result, it is now possible to deploy and undeploy repositories dynamically even when the engine is running and other repositories are in use.

A JSON schema dictates the allowed structure of the configuration files. This means they can be validated:

Problems problems = config1.validate();
if ( problems.hasProblems() ) {
    // Output a summary of the problems (with line numbers) ...
    System.out.println(problems);
}

Problems problems = config1.validate();
if ( problems.hasProblems() ) {
    // Output a summary of the problems (with line numbers) ...
    System.out.println(problems);
}

Copy to Clipboard

Toggle word wrap

Sensible defaults are in place for settings that are not configured explicitly. The following is now a valid configuration:

{ "name" : "my-repo" }

{ "name" : "my-repo" }

Copy to Clipboard

Toggle word wrap

You can now load configuration via the following means:

read from a java.io.File
read from a resolved java.net.URL
read from a String containing a URL or a path to a file on the file system or classpath
read a string containing the configuration

It is also possible to access the configuration of a running repository, change the configuration, and then update the running repository:

// Get the configuration ...
RepositoryConfiguration config = repository1.getConfiguration();

// Edit the configuration (which is a JSON document) to change a value ...
Editor editor = config.edit();
editor.getOrCreateDocument(FieldName.STORAGE)
      .getOrCreateDocument(FieldName.BINARY_STORAGE);
      .setNumber(FieldName.MINIMUM_BINARY_SIZE_IN_BYTES, newLargeValueSizeInBytes);
Changes changes = editor.getChanges();

// Apply the changes to the deployed repository ...
Future<Boolean> future = engine.update(config.getName(), changes);

// And optionally wait until the repository configuration is updated ...
future.get();

// Get the configuration ...
RepositoryConfiguration config = repository1.getConfiguration();

// Edit the configuration (which is a JSON document) to change a value ...
Editor editor = config.edit();
editor.getOrCreateDocument(FieldName.STORAGE)
      .getOrCreateDocument(FieldName.BINARY_STORAGE);
      .setNumber(FieldName.MINIMUM_BINARY_SIZE_IN_BYTES, newLargeValueSizeInBytes);
Changes changes = editor.getChanges();

// Apply the changes to the deployed repository ...
Future<Boolean> future = engine.update(config.getName(), changes);

// And optionally wait until the repository configuration is updated ...
future.get();

Copy to Clipboard

Toggle word wrap

Note

Many configuration changes can now be applied to a repository while it is running, but not everything. For example, changing where data is stored will apply only after the repository is restarted.

Migrating Content

The database system now provides efficient backup and restore functionality that works at the repository level. Each backup contains all of the content in all workspaces for a single repository. Backups can be used to restore a repository to an earlier state, and it also serves as a mechanism for migrating from the previous release.

このコンテンツは選択した言語では利用できません。

3.2. Changes to the Hierarchical Database System

詳細情報

試用、購入および販売

コミュニティー

Red Hat ドキュメントについて

多様性を受け入れるオープンソースの強化

会社概要

Theme

Red Hat legal and privacy links

Red Hat legal and privacy links