Objectives and Scope

This document discusses the different ways to group catalog elements (e.g. views, data services,...) in Denodo Virtual DataPort (VDP) and it shows the differences among them.

Development Stage: Folders

VDP Folders are designed to allow grouping catalog elements at the development stage. For instance, you could create one folder in Denodo for each use case you are developing, and a second level of folders for differentiating base views, derived views, final views consumed by applications, data services, etc. Denodo has defined a set of best practices and naming conventions to use folders in this way, but you can use any criteria that fits your development needs.

Folders do not exist for the VDP runtime environment. This allows developers to group and move elements at their convenience without worrying about consequences at runtime: for instance, suppose you have some views grouped in two folders and you decide to reorganize them to group them into three folders. You can be sure that this will not break any existing view definition or query created by another developer, and it will not affect any client application using the view.  

Runtime Stage: Databases

Grouping elements at runtime is useful because it simplifies the management of elements that have similar runtime properties (e.g. permissions, memory settings, caching configuration,...). The  way to group elements at runtime in Denodo is using databases.

Moving an element from a database to another has important consequences at runtime. For instance, moving a view from database DB1 to another database DB2 means its external name has changed (e.g. it will not be accessible in the same URL in the Denodo Generic RESTful Web Service). It also means that users which previously had permissions on DB1 but which do not have them in DB2 will no longer be able to access the element. Other runtime preferences (e.g. the used cache database) can also change.

Starting with Denodo Platform 6.0 onwards, it is possible to use elements from a database in another database. For instance, a user connected to database DB1 will be able to use elements in database DB2 to create a new view in DB1, as long as she has the required privileges on DB1 and DB2.

Notice that this allows more flexibility to group elements at runtime. For instance, you can group common elements used by several applications in a database and use those elements in other applications without needing to replicate them in other databases. This feature can also make security management easier in some scenarios. For instance, you can create a database for containing views commonly required in many applications and assign to it restrictive permissions, so conventional users can see and use these elements from other databases but cannot modify them. The same effect can be achieved by assigning permissions to the individual views, but grouping them in the same database makes it easier to manage their permissions.

Correlation between Development and Runtime Groups

Sometimes there may be a correlation between groups of elements at the development stage and at the runtime stage.

For instance, your first level of folders may correspond with use cases, and the second level may include a ’final views’ folder. Although it cannot be assumed this will always be the case, it may happen frequently that all the final views of the same use case have the same or similar permissions.

That is the reason why you can easily assign the same permissions to all the elements that are currently in the same folder, as shown in the screenshot below: