Changes in Virtual DataPort 5.0

Changes introduced in Virtual DataPort 5.0:

Some Elements are Now Case-Sensitive

Starting with Denodo 5.0, the following elements, parameters, functions, etc. are case-sensitive:

  • The connection URI to the Virtual DataPort server because the following elements are now case-sensitive:

    • Name of the database

    • Login

    • Value of the parameter i18n

  • The literals in the CONTEXT clause of a query are now case-sensitive. I.e. literals representing view names or variables.

  • The literal parameters representing maps or views in functions; type names specified as literals in functions CAST, CREATETYPEFROMXML and GETVAR; literals in functions TO_DATE, FORMATDATE and MAP; and literals representing fields in function IS_PROJECTED_FIELD.

  • The names of the jars of the stored procedures and custom wrappers. Virtual DataPort 4.7 exports these elements in lowercase to avoid conflicts when importing them into Virtual DataPort 8.0.

  • JMS listeners:

    • XML output of JMS listeners. In version 4.7, XML tags are always in lower case but in 8.0, they are in the same case as in the queried view.

    • JSON output of JMS listeners. In version 4.7, the names of the top-level fields are in upper case and the names of the subfields are in lower case. In version 8.0 the name of the fields and subfields are in the same case as in the queried view.

  • Field names in the output of JSON Web services are always in uppercase unless they were renamed. In version 4.7, they were always in lower case.

  • Web services:

    • The input parameters of REST Web services published by the Denodo Platform.

    • The URLs of the SOAP Web services. For example, let us say that you publish the SOAP Web service “orders”.

      In Denodo 4.7 and earlier versions, the following URLs are valid:

      • http://acme:9090/server/pruebas/orders/services/orders

      • http://acme:9090/server/pruebas/orders/services/ORDERS

      Starting with Denodo 5.0, the entire URL is case sensitive. Therefore, the URL http://acme:9090/server/pruebas/orders/services/ORDERS is no longer valid and it will return the HTTP error 404 (not found). You will have to use the name that matches the case of the service.

Dependencies Between Elements

Starting with Denodo 5.0, Denodo establishes a dependency between the custom maps you create and the views that use them. It also establishes a dependency between the jar files imported into the Server and the “Denodo stored procedures” and “Custom Wrappers” that use the Java classes provided by these jars.

If a user executes the statements DROP MAP 18N to delete a custom i18n map, DROP MAP SIMPLE to delete a simple map or DROP JAR to delete a jar and they have a dependency, the statement will fail. In this case, you can execute a DROP MAP I18N <name> CASCADE, DROP MAP SIMPLE <name> CASCADE or DROP JAR <name> CASCADE to delete the custom i18n map, the custom simple map or the jar file respectively. These statements delete the custom i18n map, the custom simple map or the jar file and the elements that depend on them.

The previous versions of Virtual DataPort do not establish dependencies between custom maps or jar files and the elements that use them. Therefore, in the previous versions, the statements DROP MAP I18N or DROP JAR never fail and they do not delete the elements that use the custom i18n map or the jar.

JMS Listeners

Starting with Denodo 5.0, the JMS listeners represent null values with an empty tag on the XML output. In Virtual DataPort 4.7, are represented by not adding the tag.

Stored Procedures

Starting with Denodo 5.0, the methods getXXX(<parameter name:String>) of the ResultSet objects (i.e. getString(...), getInt(...), etc.) are case sensitive. In the 4.7 version, they were not.

See the following example:

String query = "select '1' as field1 from dual()";
ResultSet resultSet = getEnvironment().executeQuery(query);
if (!resultSet.next()) {
    throw new StoredProcedureException("not found any row");
}

/*
 * The following fails in Denodo 5.0 and newer versions because the
 * "getXXX" methods of the "ResultSet" class (i.e. getString(...),
 * getInt(...), etc.) are case sensitive. That means, that the input
 * parameter has to have the same case than the name of the field in
 * the query  (i.e. "test").
 * This worked in 4.7.
 */
String text1 = resultSet.getString("Field1");

/*
 * The following works in all versions because the parameter of
 * the "getString(...)" method has the same case as the name of the
 * field in the result set.
 */
String text2 = resultSet.getString("field1");

Web Services Published by Denodo

Starting with Denodo 5.0, the option Pretty XML Output of published Web services is global for all the operations the Web service. When editing a published Web service imported from 4.7, if any operation had enabled the option Pretty XML Output, the Pretty XML Output option is enabled for the entire Web service.

Exporting to a Repository of Files

Starting with Virtual DataPort 5.0, the folder structure created when exporting to a repository of files in the local file system was simplified.

In Denodo 5.5 and 6.0, you can use the folder structure of older versions by adding the parameters --property legacyRepositoryLayout=yes and --property caseSensitive=no to the script.

Denodo 8.0 no longer supports these parameters.

See the section Using the Import/Export scripts for backup and/or replication of the Administration Guide to get additional information about these options.