Migrate selected views in Denodo at IU

• Overview
• Migrate resources
• Migrate web services
• Get help

---

Overview

In Denodo at Indiana University, developers can migrate their own resources from DEV to STG to PRD.

You can read, write, and create new objects only in the DEV environment. You can view objects in STG and PRD, but you cannot alter them in those environments. The only way to get objects into STG and PRD is through the full VDB migration process or the selected items migration process.

This document describes the selected items migration process. For a description of the full VDB process, see Migrate resources in Denodo at IU.

STG access is for testers, and PRD access is for consumers. To request access for additional users or groups to STG and/or PRD, see Use Data Delivery Apply Security to assign security to Denodo views.

Migrate resources

1. Prepare to migrate: Before migrating your resources, prepare the selected objects and data sources in the virtual database (VDB) without the _dev suffix (this is the source VDB for the selected items that will migrate). Only the selected views, associations, and web services in this VDB will be migrated; the process will not migrate data sources.

   To migrate data sources, fill out the EDSD Support Form . Under "Application", select Denodo, and under "Question Type", select Request datasource migration. Include proof of data manager approval for all data sources that contain any enterprise data. Migrate any new or modified data sources before proceeding further.

   Data sources that already exist in Staging and Production and are unchanged in Development need not be migrated again. If any required data sources are missing in Staging and Production, any objects that rely on those data sources will fail due to a missing dependency; see Migrate resources in Denodo at IU.

2. In the source VDB, you must create a materialized view listing the selected items to migrate. Optionally, you can schedule the migration to occur after a specific date and time, and/or migrate only to the Staging environment.
3. If you need to delay the migration, then first create a materialized view named migration_timestamp in the source VDB (as described below). If you want the migration to occur at the next scheduled time, then skip this step. Migrations are scheduled for 30 minutes after the hour. Your migration will occur, potentially along with others, at the first scheduled migration after the timestamp you have created. If you create no timestamp, the migration will occur at the next scheduled time.

   To create the materialized view execute the following commands in a VQL Shell in the VDB where the items to be migrated are located, substituting an appropriate value for the timestamp:

   CREATE OR REPLACE MATERIALIZED TABLE migration_timestamp (migration_time:timestamp); 
   insert into migration_timestamp (migration_time) values ('2024-10-19 12:30:00.000');

4. If you want to migrate to the Staging environment only, create a materialized view named migration_options in the source VDB (as described below); if you want to migrate to both environments, skip this step.

   CREATE OR REPLACE MATERIALIZED TABLE migration_options (migrate_to_production:boolean);
   insert into migration_options (migrate_to_production) values ('false');

5. In the source VDB, create the materialized view listing the view or views to be migrated using the VQL below, substituting the name of a valid base view, derived view, interface view, web service, or association. Multiple rows can be inserted into the materialized table:

   CREATE MATERIALIZED TABLE migration_candidates (viewname:text);
   insert into migration_candidates (viewname) values ('cache_space_status_report');

6. A Scheduler job on the Staging Environment Scheduler will process the items to be migrated in the timeframe described above. The process will confirm that the VDB exists in Staging and Production, backup any existing views in Staging and in the first of two clustered servers in the Production environment. If the import into the Staging environment succeeds, then the objects are imported into both of the clustered Production servers. If the Staging import fails, or the migrate_to_production column on the optional migration_options materialized table is set to false, then the production import is not performed.

   Email reporting the status of the migration process and relevant errors, if any, is sent to all members of the Developer security group for the source VDB in the Development environment, except group accounts. If only group accounts are members of the Developer security group then the email is sent to the EDSD Denodo support queue.

Migrate web services

If you migrate web services to production or staging and the service needs to be deployed, create a request using the EDSD Support Form .

Get help

If you have questions, or if after reviewing the results of the migration a view needs to be recovered from backup, use the EDSD Support Form to create a support request.