VCS (Visible Content Store) is the default storage engine for Nuxeo documents.
The following are the options available to configure VCS repository in Nuxeo Platform. They usually go in a file named default-repository-config.xml.
Example file
This file contains many more options than are necessary by default.
Clustering options
- clustering enabled: use true to activate Nuxeo clustering (default is false, i.e., no clustering).
- clustering delay: a configurable delay in milliseconds between two checks at the start of each transaction, to know if there are any remote invalidations.
Schema options
- field type="largetext": a field that should be stored as a CLOB column inside the database instead of a standard VARCHAR column.
This is important for your large text fields, especially for MySQL, Oracle and SQL Server which have very small defaults for standard text fields.
Using Oracle, if you attempt to save a string too big for the standard NVARCHAR2(2000) field, you will get the error:
Indexing options
Configure which types will be indexed
Since Nuxeo DM 5.5 it is possible to configure the document types you want to index or you want to exclude from fulltext indexing. This is possible using the tags includedTypes and excludedTypes inside the indexing tag:
or
If you set both included and excluded types, only the included types configuration will be taken into account.
Fulltext
- fulltext disabled: use true to disable fulltext support, the repository configuration must be updated to have (default is false, i.e., fulltext enabled).
- fulltext analyzer: a fulltext analyzer, the content of this attribute depends on the backend used:
- H2: a Lucene analyzer, for instance org.apache.lucene.analysis.fr.FrenchAnalyzer. The default is an english analyzer.
- PostgreSQL: a Text Search configuration, for instance french. The default is english. See http://www.postgresql.org/docs/8.3/static/textsearch-configuration.html
- Oracle: an Oracle PARAMETERS for fulltext, as defined by http://download.oracle.com/docs/cd/B19306_01/text.102/b14218/cdatadic.htm (see NXP-4035 for details).
- Microsoft SQL Server: a fulltext LANGUAGE, for instance english, as defined in http://msdn.microsoft.com/en-us/library/ms187787(v=SQL.90).aspx. The default is english.
- other backends don't have configurable fulltext analyzers.
- fulltext catalog: a fulltext catalog, the content of this attribute depends on the backend used:
- Microsoft SQL Server: a fulltext CATALOG, the default is nuxeo.
- other backends don't need a catalog.
Fulltext indexes are queried in NXQL through the ecm:fulltext pseudo-field. A non-default index "foo" can be queried using ecm:fulltext_foo.
If no <index> elements are present, then a default index with all string and blob fields is used.
- index name: the name of the index (the default is default).
- index analyzer: a fulltext analyzer just for this index. See fulltext options above for details.
- index catalog: a fulltext catalog just for this index. See fulltext options above for details.
- fieldType: string or blob, the default being both. This selects all these fields for indexing.
- field: the name of a field that should be selected for indexing.
- excludeField: the name of a field that should not be in the index.
If no <fieldType>, <field> or <excludeField> is present, then all string and blob fields are used.
Query Maker
- queryMaker class: registers a QueryMaker, to extend the query system. The class must implement org.nuxeo.ecm.core.storage.sql.QueryMaker (the default is org.nuxeo.ecm.core.storage.sql.NXQLQueryMaker, i.e., the standard NXQL QueryMaker).
There can be serveral <queryMaker> elements defined.
This is not needed (and deprecated) starting with Nuxeo EP 5.3.2.
Binary Store
- binaryManager class: the default Binary Manager can be changed using this (the default is to use the standard binary manager that stores files normally). A new XORBinaryManager has been added, it knows how to do XOR with a pattern on read/write (see the key below). The on-disk binary store is unchanged (the hash of the files is still the filename), but of course it's now unreadable by humans by default. One consequence is that for the same file the application-level digest in the Binary object is now different if encryption is enabled.
- binaryManager key: the encryption key for the binary manager (if it's doing any encryption). Changing this value will of course render existing binaries unreadable.
- binaryStore path: the filesystem path where the binary store should live. A relative path is interpreted relative to the Nuxeo Framework home. The default is the binaries directory.
Optimizations
- pathOptimizations enabled: for PostgreSQL, Oracle and MS SQL Server (and H2), it is possible to disable the path-based optimizations by using false (the default is true, i.e., path optimizations enabled).
- aclOptimizations enabled: for PostgreSQL, Oracle and MS SQL Server (and H2), you can disable the read ACL optimizations by using false (the default is true, i.e., ACL optimizations enabled).
- since DM 5.4.1, you can set the property readAclMaxSize to define the size of the larger ACL for a document : this may be useful if you have mainly affected permissions to a lot of users, instead of using groups (do not set this attribute if you disable ACL optimizations).
- in case the user/group names in your directories contains the separator character used in the Read ACL cache(comma by default), you can change this value using the attribute usersSeparator
- if you change this value on an existing database, you will need to rebuild the ACL cache with the SQL command:
SELECT nx_rebuild_read_acls();
Database creation option
Set the value noDDL to true to execute no DDL (Data Definition Language). The default is false.
When this is true, VCS will assume that no new structure has to be created in the database. This means that none of these statements will be executed:
- CREATE TABLE, CREATE INDEX, ALTER TABLE ADD CONSTRAINT for a new schema or complex property,
- ALTER TABLE ADD column for a new property in a schema,
- CREATE FUNCTION, CREATE PROCEDURE, CREATE TRIGGER for VCS internal stored procedures and migration steps.
The only statements that VCS will execute are:
- INSERT, UPDATE, DELETE for data changes,
- calling of stored procedures.
This means that all tables, indexes, triggers and stored procedures needed by VCS have to be created beforehand, either by a previous execution when the flag was false, or by a manual execution of a SQL script from a previously-created Nuxeo instance.
This option is typically needed if you configure the VCS connection with a username who is not the owner of the database, usually for security considerations.