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
andGETVAR
; literals in functionsTO_DATE
,FORMATDATE
andMAP
.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 5.0.
JMS listeners:
XML output of JMS listeners. In version 4.7, XML tags are always in lowercase but in 5.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 uppercase and the names of the subfields are in lowercase. In version 5.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 5.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.