IBM FileNet P8, Version 5.2.1            

Using a Custom Schema Script

You can call the overloaded createInstance method that takes a custom schema script, allowing a database administrator (DBA) to modify the factory-generated object store database schema.

A custom schema script overrides the values set by the DatabaseXXXStorageLocation properties during object store creation. Your customized schema script must be derived from one of the default (factory generated) scripts available from the ObjectStoreSchemaXXX properties on the Domain object. The properties are named ObjectStoreSchemaDB2, ObjectStoreSchemaMSSQL, and ObjectStoreSchemaOracle, and their values contain the factory-generated schema for an object store corresponding to the database vendor indicator.

A custom schema script must contain the correct version information. The version information in the header of the script must correspond to the Content Engine's schema revision level indicator, which is stored in the ObjectStore database's DDState.schema_revision_string column. When the script is retrieved from the Domain level property, it contains the correct revision level. However, in rare circumstances (usually involving an upgrade to the server after the script was retrieved), the schema revision string that is stored in the database might not match the revision information in the schema script header. Content Engine will not process the script if this indicator does not match the schema revision level that is expected by the Content Engine server and an exception is generated. The following text is an example of the version information that is found in the script header (the generation date and revision number will be different in your environment):

-- Generated for SQL Server databases on: Wed Apr 02 11:11:30 PDT 2008
-- The following SchemaRevision comment must be present and must correspond to
-- the proper schema revision level at the time the ObjectStore is created.
-- SchemaRevision: 14.1.14
Important: When customizing the script, do not alter any of the names and structures of existing tables, indexes, or columns. Doing so can cause system failures.

Note that the DB2 for z/OS script is available from the ObjectStoreSchemaDB2 property when the GCD is configured against a DB2 for z/OS database. When you modify the default database scripts, be aware that the IBM® DB2® for z/OS® script differs significantly from the scripts for IBM DB2 for Linux, UNIX and Windows, SQL Server, and Oracle, including the use of substitution placeholders. Each substitution variable is surrounded by a question mark character (?) and the variable name corresponds to a string-valued custom property name specified during IBM DB2 for z/OS configuration. The following excerpt shows how this variable is used within the script (the ellipses in this example indicate additional statements that have been deleted for brevity):

CREATE TABLE DocVersion(object_id varchar(16) for bit data NOT NULL PRIMARY KEY , object_class_id varchar(16) for bit data NOT NULL , security_id varchar(16) for bit data NOT NULL
, … , security_folder_id varchar(16) for bit data ) IN DATABASE ?zOSDatabaseName?
CREATE INDEX I_DocVersion22 ON DocVersion (version_series_id, major_version_number DESC, minor_version_number DESC)  
USING STOGROUP ?zOSDefaultSTOGROUP? ?zOSSTOGROUPOptions?
…

Compare the previous example with the following WebSphere® Application Server script (the ellipses indicate additional statements that are deleted for brevity):

CREATE TABLE DocVersion(object_id uniqueidentifier NOT NULL PRIMARY KEY , object_class_id uniqueidentifier NOT NULL , security_id uniqueidentifier NOT NULL , 
… , security_folder_id uniqueidentifier )
CREATE INDEX I_DocVersion22 ON DocVersion (version_series_id, major_version_number DESC, minor_version_number DESC)
…


Last updated: October 2015
objectstore_schema_concepts.htm

© Copyright IBM Corporation 2015.