Export the Metadata of the Current Installation¶
You only need to export the metadata of the modules that you installed in the current setup of the Denodo Platform.
Install the latest update for the Denodo Platform 6.0 on the current installation. To obtain the latest update, go to the support site.
If you do not want to install permanently the latest update on the current installation, follow these steps:
Stop all the servers of the current installation.
Make a copy of the folder of the current installation.
Install the latest update of Denodo 6.0.
Perform the steps explained in this section.
Delete the folder of the installation with the latest and put back in place the folder copied in step ii.
Start the Virtual DataPort server and its administration tool of the current installation (i.e. v6.0).
In Denodo 7.0, you can no longer publish web services with the authentication methods “HTTP Basic with LDAP” nor “WSS Basic with LDAP”. Modify the web services that use these authentication methods before importing the VQL file into Denodo 7.0. You can either modify the web service from Denodo 6.0 or modify the VQL file manually.
To search the web services that use these authentication methods, export the VQL of Denodo 6.0 and search for
WSS BASIC LDAPand
BASIC LDAP(inside the statements
CREATE REST WEBSERVICEand
CREATE SOAP WEBSERVICE).
We suggest moving to “HTTP Basic with VDP” or “WSS Basic with VDP” so the web services leverage the authentication layer of Denodo. See more about this in the section Web Services Authentication.
Log in as an administrator, open the VQL Shell and execute this:
SET 'com.denodo.vdb.catalog.exportMigrationCompatibility' = 'true';
This property makes the Virtual DataPort server to generate VQL statements adapted for Denodo 7.0. This property is only useful when upgrading from Denodo 6.0, Denodo 5.5 or 5.0. It does not do anything in earlier versions.
Setting this property is necessary because:
Denodo 6.0 and Denodo 7.0 introduce minor changes to the VQL syntax to avoid ambiguities in the parsing of VQL statements. These changes are not backwards compatible with earlier versions.
With this property, Virtual DataPort generates VQL statements that are compatible with Denodo 7.0. The section Changes in VQL Syntax lists these changes.
In Denodo 7.0, Denodo databases no longer have their own i18n configuration. Instead, they use the i18n configuration of the Denodo server. Because of this change, the statement
ALTER DATABASEno longer admits the parameter
I18N. If you export from Denodo 6.0 and you set this property, the statements
ALTER DATABASEwill not have this parameter.
If you export from Denodo 6.0, the VQL statements that create stored procedures will include the parameter
USE_DENODO_6_0_TYPE_MAPPING. This parameter instructs the Denodo server 7.0 to handle the input and output parameters of these procedures as in Denodo 6.0.
The section changes in Virtual DataPort 7.0 provides more details about the changes in the VQL syntax.
Execute this to generate VQL statements so the views take advantage of the new data types for date fields.
SET 'com.denodo.vdb.catalog.exportMigrationCompatibility.migrateDateTypes' = 'true';
This property is only useful when upgrading from Denodo 6.0. Previous versions ignore this property.
Denodo 7.0 provides new types for date and timestamp values:
timestamptz. These types provide several advantages over the existing
dateis still supported to keep backward compatibility.
Without this property, the fields of type
dateare exported with the same type.
With this property, the Denodo server analyzes the
datefields to see if they can be exported to one of the new types:
For JDBC base views, Virtual DataPort looks at the field “sourceTypeName” of the statement
CREATE WRAPPER JDBCof the base view, and the adapter of the data source of the base view. With this information, it will export the date fields with one of the new types.
For non-JDBC base views or derived views, it looks into the property “sourceTypeId” of the field of the
If the property “sourceTypeId” is
DATE, the field is exported as
localdate, which is the name of the type in Denodo to represent date values without time (equivalent to type DATE of SQL).
If it is
TIME, the field is exported as
If it is
TIMESTAMP, the field is exported as
date(deprecated). There is not enough information to know if the field is timestamp or timestamptz.
If the field does not have a source type, the field is exported as
In the following cases, the fields of type
datewill remain with the same type because there is not enough information to select one of the new date types:
Non-JDBC base views whose fields do not have the source type id defined.
Fields of derived views that are an expression that is the result of applying the function
After importing the VQL file into the Denodo 7.0 server, you can use the stored procedure MIGRATE_DATE_TYPES to change the type of these fields automatically.
We suggest setting the property “migrateDateTypes” because, although it may introduce a few backward compatibility issues with existing clients, these can be quickly solved. In the long run, by using the new date types, you will avoid the problems introduced by the fact that the
datetype in Denodo represents a timestamp with time zone while in many cases the underlying column in the SQL table has a type without time zone.
If you do not set the property “com.denodo.vdb.catalog.exportMigrationCompatibility.migrateDateTypes” before doing the export, you can still import the VQL file into the Denodo 7.0 server and then, use MIGRATE_DATE_TYPES to change the type of these fields automatically.
Restart the Virtual DataPort server to apply the change to the value of these properties.
Start all the servers of the old installation. If Virtual DataPort was already started, restart it to apply the change of the previous step.
Export the metadata of Virtual DataPort and the ITPilot’s Wrapper server using the script export of the current installation. To do this, open a command line and execute this:
cd <OLD_DENODO_HOME> cd bin export --login <login of an administrator user> --password <password> --server localhost:9999 -f export_from_denodo_60.vql -P includeJars=yes -P includeScanners=yes -P includeCustomComponents=yes -P includeStatistics=yes -P includeDeployments=yes -P replaceExistingElements=yes -P dropElements=no -P excludeServerConfigurationProperties=com.denodo.vdb.vdbinterface.server.VDBManagerImpl.registryURL,com.denodo.vdb.vdbinterface.server.VDBManagerImpl.registryPort,com.denodo.vdb.vdbinterface.server.VDBManagerImpl.shutdownPort,com.denodo.vdb.vdbinterface.server.VDBManagerImpl.factoryPort,com.denodo.vdb.vdbinterface.server.VDBManagerImpl.odbcPort,com.denodo.vdb.cache.cacheMaintenance,java.env.DENODO_OPTS_START,java.env.DENODO_OPTS_STOP -P excludeWebContainerConfigurationProperties=com.denodo.tomcat.jmx.rmi.port,com.denodo.tomcat.http.port,com.denodo.tomcat.shutdown.port,com.denodo.tomcat.jmx.port,java.env.DENODO_OPTS_START,java.env.DENODO_OPTS_STOP
Export the metadata from the ITPilot Wrapper Generation Tool: open the Wrapper Generation Tool and click File > Export.
The section Migrating Wrappers Between Generation Environments: Import and Export of the ITPilot Generation Environment Guide provides more details about this.
Export the metadata from Scheduler: use the export script located in
The section Use of the import/export scripts for backup explains how to use this script.
Export all the saved queries of all users from Information Self-Service Tool:
The section Saved Queries provides more details about this step.
On the administration tool of Virtual DataPort, execute this:
SET 'com.denodo.vdb.catalog.exportMigrationCompatibility' = 'false'; SET 'com.denodo.vdb.catalog.exportMigrationCompatibility.migrateDateTypes' = 'false';
After setting these properties to false and restarting, the VQL will go back to being generated with the usual syntax.
Restart the Virtual DataPort server.