Oracle Analytics Cloud and Server Idea Lab

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

Planned
752
Views
17
Comments

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

42
42 votes

Planned · Last Updated

Comments

  • Branden Pavol
    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.

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

  • Michal Zima
    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

  • 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
    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
    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.

  • 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.
  • 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.

  • @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
    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:

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

    Thanks

    Michal

  • Our organization needs this desperately too.

    I just promoted 8 workbooks up through our 5 database tiers, ending in Prod. Since I cannot repoint Datasets to different (identical in table structure) Connections, I had to MANUALLY recreate Datasets 32 times. It was super error prone, and I think my brain died a little in the process.

    How can I recommend Oracle analytics to anyone if this essential feature, that practically all companies need, has not been addressed in several years since the issue was raised?

    🤕

  • Going to chime in to say that this feature is absolutely crucial to our organization. It is impossible to maintain a meaningful development cycle without the ability to easily change connection information without losing all dataset changes. This basically forces us to recreate datasets multiple times and makes having multiple instances of OAC almost completely pointless. I've been documenting possible workflows for our upcoming implementation, and they are so insecure and cumbersome that I am having trouble conceiving how Oracle even imagines it should work.

    We currently use Tableau and their data sources are extremely easy to migrate because you can just edit the connection without losing any metadata. If OAC is supposed to be a competitor for groups that aren't 100% self-service, then it needs to support more than just self-service in a production environment.

  • Michal Zima
    Michal Zima ✭✭✭✭✭
    edited May 15

    Can somebody from Product Mgmt/Development shed some light on what status "Option for Future Release" mean ? How long it will take to have it implemented ? Apparently this feature (and also other features, around deployment/Dev2Prod  in DV) are not of high priority - despite the fact, that they are terribly missing in the product, very much complicating live for real enterprise deployments of DV where governance plays important role (not just couple of users, having complete freedom to do what they want…). So I would really expect here more "focus" and "goal kick" and prioritize those features to be implemented ASAP in product - please…..

  • Greg Faris
    Greg Faris ✭✭✭✭

    I agree with Michael. This is very problematic when you have 1000s of datasets in an enterprise deployment. What can we do to get this fast-tracked?

  • Greg Faris
    Greg Faris ✭✭✭✭

    @Benjamin Arnulf-Oracle @Gabby Rubin-Oracle Could we please get an update on the delivery timeframe? This has been a need for quite some time, and it shows Option for Future Release. Thanks!

  • @Greg Faris Checking with @Alan Lee - Oracle-Oracle and @Bret Grinslade - Oracle Analytics-Oracle . They might directly answer here or I will get an update.

  • The improvement is on the roadmap. We don't have a target release date yet.