Changes in Virtual DataPort 8.0 GA¶
This section lists the changed introduced in Virtual DataPort 8.0 GA compared to Virtual DataPort 7.0.
The default configuration of Virtual DataPort now has assigned 4 gigabytes of RAM instead of 1 (parameter
-Xmx). The goal is to make the configuration closer to what it should be on a production environment.
The Virtual DataPort of the installation of Solution Manager still only uses 1 gigabyte per default.
Connections Only Use One Port¶
The JDBC driver, the administration tool and the new Design Studio now use a single port to communicate with Virtual DataPort (9999). In previous versions, the communication requires two ports (9999 and 9997). This change simplifies the configuration of firewalls.
JMX connections still use two ports: 9997 (main port) and 9995 (auxiliary port) but they are different than in Denodo 7.0 (in Denodo 7.0, the JMX connections use 9999 and 9997). If there is a firewall between Virtual DataPort and its monitoring clients, update the configuration of your firewall to allow connections to the ports 9997 and 9995.
JDBC Data Sources¶
JDBC Data Sources: Location of Drivers¶
Do not copy JDBC drivers or any other jar files, dll files or any other libraries to the installation. Instead, upload them using the wizard of the menu File > Extensions management of the Administration Tool.
See more about this in the section Importing Extensions of the Administration Guide.
JDBC Data Sources: Some Adapters Have Been Removed¶
It is no longer supported to connect to the following versions of Microsoft SQL Server, using the jTDS driver: 2014 and 2016.
It is no longer supported to connect to the following versions of Microsoft SQL Server, using the official JDBC driver of Microsoft: 2000 and 2005.
These adapters have been removed because officially, the jTDS driver does not support connecting to newer versions of SQL Server and the Microsoft JDBC driver does not officially support the oldest ones.
Queries Always Obtain the Execution Trace¶
The check box Execute with TRACE has been removed from the dialog to query views, and the administration tool always obtains the execution trace from the queries.
In previous versions, if this check box is selected, the administration tool adds the clause
TRACE to the query in order to obtain the execution trace of the query. Now, this clause is always added to the queries.
Getting/Setting Configuration Properties¶
From now on, always use the command SET to change the value of a property instead of modifying the file
<DENODO_HOME>/conf/vdp/VDBConfiguration.properties. This is particularly important, when you configured Virtual DataPort to store its configuration and metadata on an external database. With
SET, the changes in properties are propagated to the other servers.
For many configuration properties, when you change their value using
SET, the change is applied immediately. If you change the value in the configuration file, you always have to restart. In addition, it reduces the amount of users may require to connect to the computer where Denodo is running.
In addition, you can obtain the values of a configuration property using the new stored procedure GET_PARAMETER. This is more convenient than connecting to the computer to obtain the value of a parameter in
This version does not include any change that breaks backward compatibility with any northbound application that executes SQL statements. That is, all the queries that work in version 7.0, work in the new version.
Starting with Denodo 8.0, only global administrators can execute the command WEBCONTAINER SET. In Denodo 7.0, users with the privileges “Connect” and “Write” over the database they are connected to can also execute this command.
Roles for the Solution Manager and JMXAdmin¶
Virtual DataPort no longer defines the following roles:
In Virtual DataPort 7.0, these roles are created automatically in Virtual DataPort. They were meant to be used to grant the privilege of doing certain tasks on the Solution Manager.
If you were using them for other purposes, you can create them. However, consider that because they are not “default roles”, they now can be deleted.
The Virtual DataPort installed with the Solution Manager continues to have these roles. However, they are meant to be managed from the new user interface of the Solution Manager, not using the administration tool of Virtual DataPort.
The role “jmxadmin” is now deprecated. See more about this in the section Role JMXAdmin of the list of Features Deprecated in Virtual DataPort 8.0.
Column Privileges, Row Restrictions and Custom Policies Are Always Propagated¶
In Denodo 7.0, by default, the Execution Engine only applies column privileges, row restrictions and custom policies granted over a view to a user/role, when this view is directly referenced from the statement.
Denodo 8.0 always enforces the column/row restrictions and custom policies regardless of if the view is directly or indirectly involved in the statement. This behavior is already available in 7.0 but it is disabled by default.
For example, let us say you define a column restriction for the role “developer” over the view “employee”. This restriction forbids this role to project the column “salary”.
If a user with this role executes the following query, the query will fail in Denodo 7.0 and 8.0:
SELECT ename, salary FROM employee
However, if another user created the following view:
CREATE VIEW employee_dept1 AS SELECT ename, salary FROM employee WHERE deptno = 1
In Denodo 8.0, this query will fail for a lack of privileges.
To restore the behavior of Denodo 7.0, follow these steps:
Log in to the administration tool with an administrator account.
Execute this from the VQL Shell:
SET 'com.denodo.vdb.catalog.user.User.enableCheckViewRestrictionAlways' = 'false';
The change is applied immediately, you do not need to restart.
If you want to restore the old behavior but only on certain databases, execute this:
SET 'com.denodo.vdb.catalog.user.User.checkViewRestrictionAlways' = 'true'; ALTER DATABASE <database> CHECK_VIEW_RESTRICTIONS DIRECT_QUERIES_ONLY;
The change is applied immediately, you do not need to restart.
If in the future, you want this database to always enforce these restrictions, execute this:
ALTER DATABASE <database> DEFAULT;
DEFAULT, the database follows the behavior specified by the property
This affect queries (SELECT) and INSERT, UPDATE and DELETE statements
XML Representation of Array-Type Values¶
In Denodo 7.0, by default, Denodo REST web services simplified the XML representation of array-type fields that only have one sub-field by returning only the subfield, without the enclosing array.
The information on this subsection is related to the XML representation, not the HTML nor the JSON representations.
For instance, consider a web service that publishes a view with this schema:
In 7.0, the service would represent the data with this XML document:
<test_view> <f_n> <f1>10</f1> <f2>20</f2> </f_n> <f_n> <f1>10</f1> <f2>20</f2> </f_n> <f_n> <f1>10</f1> <f2>20</f2> </f_n> <f_n> <f1>10</f1> <f2>20</f2> </f_n> </test_view>
Note that the array “f_n_n” is not in the result, only the register “f_n”.
In Denodo 8.0, the service of the example outputs this XML by default:
<test_view> <f_n_n> <f_n> <f1>10</f1> <f2>20</f2> </f_n> <f_n> <f1>10</f1> <f2>20</f2> </f_n> </f_n_n> <f_n_n> <f_n> <f1>10</f1> <f2>20</f2> </f_n> <f_n> <f1>10</f1> <f2>20</f2> </f_n> </f_n_n> </test_view>
To restore the behavior of the version 7.0, follow these steps:
Execute the following command:
SET 'com.denodo.wsgenerator.restws.xmlArraySimpleOutput' = 'true';
Redeploy all the REST web services. The changes to this property are applied to a web service when you redeploy the web service.
RESTful Web Service: Parameter $select Allows Expressions¶
This section is in regards of the RESTful web service of Denodo (i.e. https://denodo-server.acme.com:9090/denodo-restfulws), not the REST web services.
In previous versions, the value of the input parameter “$select” can only be a list of fields separated by comma but the service can be configured to allow expressions as well.
In version 8.0, the parameter “$select” processes expressions by default. For example, you can invoke this:
https://denodo-server.acme.com:9443/denodo-restfulws/customer360/views/customer?$select=concat(last_name, ', ' , first_name) AS full_name, upper(state)
(for clarity, this URL is not escaped)
To restore the behavior of previous versions, follow these steps:
Log in to Virtual DataPort with an administrator account and execute this:
Edit the file
<DENODO_HOME>/resources/apache-tomcat/webapps/denodo-restfulws/WEB-INF/other_settings.xmland search for the entry
processFunctionsInSelectParameter; change its value to
Execute this command:
This change only affects the global RESTful web service. You can control this feature for each REST web service with the option Process functions in $select parameter (tab Advanced of the configuration of the service).
In Denodo 8.0, Virtual DataPort transfers data into Presto using non-managed (external) Hive tables. By using external tables, the URI configured to upload the data files can be different than the location of the schema used for caching or perform data movements. Make sure the configuration property of Presto
true; otherwise, the process of storing data in Presto will fail. To restore the behavior of Denodo 7.0 (i.e. not using external tables), execute this:
You do not need to restart to apply this change.