Default values are used only if repository is in embedded mode, otherwise configuration validation fails.
|database||Simplified option for repository setup. Possible values are h2, mysql, oracle, sqlserver, postgresql. This option will set defaults for other options, for example embedded, hibernateHbm2ddl, hibernateDialect and driverClassName based on selected database. These defaults can be overridden by specifying custom values in configuration.||h2|
Drops database files if they exist during start. Useful for tests.
Directory where H2 files will be saved if we're running in embedded mode.
current folder "."
Database filename. Name for H2 files if we're running in embedded mode.
Embedded H2 mode.
This option can be used if we're running in H2 embedded mode. If the server mode is turned on, H2 runs with TCP server. Other applications/services can connect to H2 server. If false, H2 runs in file mode.
Embedded H2 server mode SSL.
Embedded H2 server mode port.
Automatically validates or exports schema DDL to the database when the SessionFactory is created. E.g.
For production environments,
SQL dialect based on choosen DB Supported hibernate dialects.
Uses JNDI DataSource loading, when this option is defined in configuration, then jdbcUsername, jdbcPassword, jdbcUrl and driverClassName don't need to be present. E.g. <dataSource>java:comp/env/jdbc/midpoint</dataSource>
Username for JDBC connection.
sa (if embedded=true)
Password for JDBC connection.
empty string (if embedded=true)
URL for JDBC conection.
if embedded=true url is computed from previous parameters
Driver class name for JDBC connection.
org.h2.Driver (if embedded=true)
|useZip||Property provides optional compression for full XML column.||false|
|minPoolSize||Minimal # of connections in connection pool, if connection pool is not provided through dataSource.||8|
|maxPoolSize||Maximum # of connections in connection pool, if connection pool is not provided through dataSource.||20|
|cacheMaxTTL||Option which can enable caching of selected object types (ConnectorType, ObjectTemplateType, SecurityPolicyType, SystemConfigurationType and ValuePolicyType). Objects are cached and reloaded only if object version doesn't match. Version check happens only after time to live (TTL) period has passed. Value in seconds.||0|
|initializationFailTimeout||Hikari pool initialization failure timeout, in milliseconds. It is there to allow midPoint to wait until the repository is up and running and therefore to avoid failing prematurely. Introduced in midPoint 3.9.||1 ms (effectively keeping the behavior as it was before midPoint 3.9)|
Schema validation and maintenance is the driven by these configuration options:
|skipExplicitSchemaValidation||Whether to skip this process of explicit schema validation.|
What to do if the database schema is not present:
What to do if the database schema is present but it is outdated and it seems to be upgradeable:
Note that currently (as of 3.9) the only supported automated upgrade is from 3.8 to 3.9.
Please consider carefully whether you want to run this automatic upgrade also for the production environment. It is perhaps better to still run the upgrade manually in such situation.
What to do if the database schema is present, is not compatible and not upgradeable. A typical example is when the schema is newer than the current version of midPoint.
|schemaVersionIfMissing||If the schema version cannot be determined from ||(none)|
|schemaVersionOverride||Overrides any schema version information in the ||(none)|
Used to specify what schema variant is to be used for automated creation or upgrade of the database schema. Currently the only known variant is
Beware: it is the administrator's responsibility to choose the correct variant! Currently midPoint does not try to determine the variant present in the database. So be sure to avoid applying e.g.
Schema creation and updating (before 3.9)
First step is DB resource configuration in application server. Here is example for Tomcat 7. This XML part is located in
<tomcat-location>/conf/server.xml, resource will be available for all applications in container.
Code Block language html/xml linenumbers true
<GlobalNamingResources> <Resource name="jdbc/mysql" auth="Container" type="javax.sql.DataSource" username="MYSQL_USER" password="MYSQL_USER_PASSWORD" url="jdbc:mysql://localhost:3306/midpoint-big" driverClassName="com.mysql.jdbc.Driver" accessToUnderlyingConnectionAllowed="true" initialSize="5" maxWait="5000" maxActive="30" maxIdle="5" validationQuery="select 1" poolPreparedStatements="true"/> </GlobalNamingResources>
Code Block language html/xml
<?xml version='1.0' encoding='utf-8'?> <Context> <WatchedResource>WEB-INF/web.xml</WatchedResource> <ResourceLink name="jdbc/mysql" global="jdbc/mysql" type="javax.sql.DataSource"/> </Context>
Next step is configuration in file
config.xmllocated in midpoint.home folder.
hibernateDialectdepends on your DB choice,
dataSourceis based on resource name.
Code Block language html/xml linenumbers true
<configuration> <midpoint> <repository> <repositoryServiceFactoryClass>com.evolveum.midpoint.repo.sql.SqlRepositoryFactory</repositoryServiceFactoryClass> <embedded>false</embedded> <hibernateDialect>com.evolveum.midpoint.repo.sql.util.MidPointMySQLDialect</hibernateDialect> <hibernateHbm2ddl>validate</hibernateHbm2ddl> <dataSource>java:comp/env/jdbc/mysql</dataSource> </repository> </midpoint> </configuration>
It is currently not possible to set up data sources with standalone configuration (i.e. when using embedded Tomcat). We are perfectly capable to implement, fix and finish the feature, just the funding for the work is needed. Please consider the possibility for supporting development of this feature by means of midPoint Platform subscription. If you already are midPoint Platform subscriber and this feature is within the goals of your deployment you may be able to use your subscription to endorse implementation of this feature.