MDM SQL Storage - 8.0

English (United States)
Talend Data Fabric
Talend MDM Platform
Talend MDM Server
Installation and Upgrade

MDM SQL Storage

A new storage for MDM based on SQL allows MDM to store user data on a Relational Database Management System (RDBMS).

MDM stored procedures need to be written using SQL statements since the query is directly executed against the underlying database (when using an XML database, stored procedures were written using XQuery).

For suggestions on how to handle any issues you may encounter with MDM SQL Storage, see Troubleshooting for MDM SQL Storage.

Working principles of MDM SQL storage

In MDM, user containers are used to host master and staging data, while system containers are used to store MDM-specific data, for example, the information of users and view definitions.

There is no difference between system containers and user containers since both can use SQL storage.

All non-user defined data containers are considered as system containers except UpdateReport. Since this container uses a well-defined format, it is stored in SQL databases when SQL storage is enabled.

When MDM receives a request that may be a query, a "create record" request, or an "update record" request, it first identifies whether the request is on a system container or a user container, and then forwards this request to the right storage.

Each SQL storage is independent: it has its own connection pool and configuration. This is important as it directly impacts the number of connections MDM establishes with the SQL databases. If you have two data containers and a minimum of 20 connections, it means MDM will create 40 (20*2) connections during startup.

To support different types of RDBMS, SQL storage uses Hibernate internally to support multiple database types.

For more information about Hibernate, see

Common configurations for using MDM SQL storage

Once the MDM server installation is done, you need to carry out some configuration tasks before using MDM SQL storage.


  1. Go to the directory where you installed Talend MDM and open the file mdm.conf under the directory <mdm_dir>\conf.
  2. Make sure that the configuration is correct, as shown below.

    These properties are explained in the following table:




    Indicates to MDM whether it should try (or not) to create database on its own. By default, it is true.


    Points to a file that provides connection information to the database. There is no default value for this property. The installer deploys a file named “datasources.xml”. MDM looks for the file in the following order:

    1. In the folder that system property “jboss.server.home.dir” points to.
    2. At the root of the classpath of MDM application.


    Tells MDM what default datasource in the db.datasources file should be used. You may have different datasources such as “MySQL-Dev” and “MySQL-Prod” and use this property to switch from an environment to another.

    In this example, mdm.conf sets autoPrepare to true, uses the file datasources.xml as datasource configuration and the defaultDataSource is MySQL-Default.

  3. Under the same directory, open the file datasources.xml to check the datasource configuration.
    <datasources xmlns=”"”>
        <datasource name=”MySQL-DS1> <!-- (1) -->  
                <type>RDBMS</type> <!-- (2) -->
                    <dialect>MySQL</dialect> <!-- (3) -->
                    <connection-driver-class>com.mysql.jdbc.Driver</connection-driver-class> <!-- (4) -->
                    <connection-url>jdbc:mysql://</connection-url> <!-- (5) -->
                    <connection-username>root</connection-username> <!-- (6) -->
                    <connection-password>toor</connection-password> <!-- (7) -->
                    <fulltext-index-directory>/var/lucene/indexes/DS1</fulltext-index-directory> <!-- (8) -->
                    <cache-directory>/var/cache/DS1</cache-directory> <!-- (9) -->
                    <contains-optimization>fulltext|disabled|like</contains-optimization> <!-- (10) -->
                    <schema-generation>update</schema-generation>  <!-- (11) -->
                        <property name="hibernate.show_sql">false</property> <!-- (12)-->
                        <database-name>mdm_dev1</database-name> <!-- (13) -->
                        <connection-url>jdbc:mysql://</connection-url> <!-- (14) -->
                        <connection-username>root</connection-username> <!-- (15) -->
                        <connection-password>toor</connection-password> <!-- (16) -->
                <!-- same content: this configures database for the staging area -->
                <!-- same content: this configures database for the system storage -->

    See below for the explanation of each property in the datasource configuration file:

    • (1) A unique name that identifies the datasource.
    • (2) Tells MDM what kind of data source it is. Only RDBMS value is currently supported.
    • (3) Specifies a dialect for MDM to use specific SQL query generators for the database.
    • (4) JDBC driver class. Note that class has to be present in the MDM server classpath.
    • (5) JDBC connection URL. It is usually dependent on the JDBC driver.
    • (6) Connection user name.
    • (7) Connection password.
    • (8) This SQL storage still allows full text searches and this property tells MDM where the full text indices should be stored on the disk. If this property is missing, the storage will not be able to perform full text search.
    • (9) This property tells MDM where second level cache should store information (second level cache leverages EHCache). If this property is missing, the storage will not use second level cache (this does not bring much improvements since MDM already uses first level cache of Hibernate, this may become handy for large volumes of data with many requests for random records).
    • (10) Type of "contains" query optimization: "fulltext" (default) indicates MDM should use full-text queries for contains when applicable, "like" means MDM should use database "LIKE" statements, and "disabled" means MDM will throw an exception every time a "contains" query is processed.
    • (11) Indicates the type of actions to be taken on the database schema.

      Three values are valid for the schema-generation element:




      Update existing schema: add columns for newly added elements to an entity. This does not remove previous constraints nor previous elements you removed.


      Drop existing tables before re-creating tables. You can use this mode when you are not sure of the data model yet. This removes obsolete constraints and columns as well as previous data.


      Make no schema change. Ensure that database schema will be able to store MDM records. In case of error(s), initialization of SQL storage fails. Check your server's log or console for more information.

      When <schema-generation> is set to "create", schema creation errors do not stop SQL storage initialization: Hibernate generates SQL statements that fail when you start on an empty database. To see these errors, enable Log4j category "" at the DEBUG level.

    • (12) This example indicates whether to show SQL statements on the console or not. If it is set to true, all the SQL statements will be written to the console. You may enable this option for troubleshooting purposes. Note that verbose information will be output after you enable this option.
    • (13) Name of the database: this is used during storage initialization when the autoPrepare option is true in the file mdm.conf. MDM will try to create a database named after this value on storage initialization.
    • (14) (15) (16) When autoPrepare is enabled, those credentials are used to create a database named after (13).

    Everything contained in the “properties” is passed “as is” to Hibernate configuration. All properties in this configuration section overrides the configuration MDM generates (no validation or control is performed on the values passed here). You may consult Hibernate documentation to get more information on the properties you can set.

Using variables in the datasource configuration file

You may use variables in the datasource configuration.

For example, use the variable ${container} in the datasources configuration.

<datasources xmlns="">
    <datasource name="MySQL-DS1">

The variable ${container} will be replaced by the data container name when it is being created.

For example, when a container "Product" is created, the <connection-url> element will be "jdbc:mysql:". The <database-name> element will be replaced by the value "Product" too.

The <connection-username> element also accepts the ${container} variable.

Note that when using variables in the datasource configuration file,

  • for Oracle, one database with different schemas is created for master, staging, and system, and all tables for different containers are created in the corresponding schema. The table cannot be removed when undeploying the corresponding container.
  • for other database types, one database is created for each container. The database can be removed automatically when undeploying the corresponding container.

You can retrieve the datasource configuration file datasources.xml on the Downloads tab of this page to find more examples of using variables for different types of databases.

Using multiple database vendors in the datasource configuration file

You can use different database vendors for the different MDM storages.

For example, MySQL may be used for the user data, H2 for staging and Oracle for system objects.

<datasources xmlns="">
    <datasource name="RDBMS-1">

Database Specific Configurations for Using MDM SQL Storage

Since MDM supports different types of databases, you can perform specific configurations for each of them.

SQL Server 2008

SQL Server 2008 can rapidly run into concurrent issues with deadlocks upon insert or updates. This kind of issue appears very rapidly, and it does not require a heavy load.

To fix this issue, you need to configure your SQL Server instance. Run the following SQL:


Using MDM SQL storage


  1. Ensure that the configurations are correct depending on the database you are using.
  2. In Talend MDM studio, deploy a data model named Product.
    The name of the data container must be the same as that of the data model. To initialize a SQL storage, it needs the metadata of the entities it will manage since the database schema is derived from the entities. There is currently no mapping between a data container and the data model(s) it will manage, so the naming convention must be followed.
  3. Create a data container Product and deploy it to the server.
    You may select both data model and data container in the repository and deploy them to the server. MDM will then re-order the deployments in correct order (first data model and then data container).