Oracle Communities

Oracle Analytics and AI

Child Item

Ability to easily change connection assigned to external (database) data set in DV

Organization Name

CESKA NARODNI BANKA

Description

It would be really great, if there would be an option (similar to easily switch between data sources in RPD by modifying connection info in Connection Pool) for external (database) data set to change Connection assigned to this data set (changing the property "Connection" for data set). This will give good flexibility to "redirect" data set to different DB (for example easily switching from DEV Db to TEST Db). From deployment/DevOps point of view, this is "must-have" feature.

Use Case and Business Need

Flexible redirection of external data set to different location (Db). Must have feature from deployment/DevOps point of view.

Original Idea Number: c3158a1c2e

Find more posts tagged with

Delivered

Data Connectivity

Data Modelling and Datasets

Administration

Status: Delivered

Comments

Branden Pavol

I agree that this is a must have feature. The only way around this is to rebuild the dataset from scratch against the different databases. We need to be able to develop in DEV against a non-prod database then promote that dataset to production and swap out the connection to use the prod database. Otherwise, Oracle is promoting the process of developing in production which is clearly not ideal.

Robert Corrieri-281169

Our organization is in need of this as well. This will become a change management nightmare if this feature is not enabled.

Michal Zima

Is anybody from development looking at this Idea ? It hase been created almost 2 yers ago and it it still in Submitted status. Thanks

Alan Lee - Oracle-Oracle

Oracle is reviewing options to more gracefully migrate datasets with associated connections between environments, e.g avoid overwriting connection details in the target environment.

Michal Zima

@Alan Lee - Oracle-Oracle .Hi Alan, looking forward for better way to migrate DV objects between environments. Current status via DVA package is very very limiting. What I would suggest as well for improvement (except being able to change/assign different Connection on target environment) is possibility (when chosen) to “preserve” namespace (thus ID of user who created object on source environment) and also owner of object from source environment when migrating DV object to target environment. Current DVA package functionality assign to both this ID of user, who performed import of DVA package on target environment - which is in our organization administrator of environment (to which DVA package had been passed from authors from source environment). And thus we are completely loosing on target environment “the trace” who is the real creator/owner of DV object (from source environment). So pls, considet this option within your revision (as you mentioned). Thanks

Branden Pavol

My team and I have recently made a rule that we CANNOT use the import DVA feature AT ALL because it breaks way too many things in the process, such as permissions. Anxiously looking forward to improvement here. Current state, we have resorted to rebuilding everything from scratch because that is the only way we know it will work without breaking something else in the process.

Sean McArthur

The ability to switch the connection of a dataset would be of huge value to our organization.

Use cases:

swapping between environments in a migration path
swapping between databases
swapping ownership of datasets/connections allowing creation of a dataset and transferring to someone else that can truly "own" and edit the definition of the dataset. DV won't allow the definition to be edited unless both the dataset and connection are owned.

Jennifer Fairchild

The ability to transfer ownership of datasets and connections was a nice first step, but does not solve the problem at large. We see use cases where individuals have changed job functions or orgs and need to transfer datasets to a new responsible person, but retain their connection. We also see use cases where creation of the dataset should occur against DEV or QA DW and then change to PRD. Use cases also exist for people leaving the company and transferring their datasets to someone else, but now that person has to maintain multiple connections generally to the same DBs, which is cumbersome and inefficient. All of these use cases would be solved by the ability to change the connection a dataset uses as the owner of the dataset - without having access to the existing connection the dataset is using.

Bret Grinslade - Oracle Analytics-Oracle

@Sean McArthur for the comment on edit definition -- you need read access to a connnection (that is the ability to use it) to edit definition. You don't need the ability to modify a connection to use edit definition. If you are seeing something else, let us know.

For the overall topic - we looking at options.

Michal Zima

@Bret Grinslade - Oracle Analytics-Oracle Bret, good to hear, that "you are looking at options". But what is a sad story is a fact, that this Idea has been created in June 2020 (so it is almost 3 years old) and so far there does not seem to be any solution implemented (not even planned in roadmap). I have summarized all paint points around deployment/Dev2Prod DV product gaps in discussion within this Idea:

https://community.oracle.com/products/oracleanalytics/discussion/comment/51083#Comment_51083

So I am more than curious to hear about some good news in this area.

Thanks

Michal