We have multiple Data Vault 2.0 (DV) engineers.
Situation: Our challenge is that we don’t have a solution to prevent collisions in WhereScape RED.
Complication: The more engineers we add the more issues with models being overwritten. Of course, we chat and say “I am working on the provider domain” and such. But it would be easier if there was a process or technology solution to prevent collisions.
Ask: Looking for a potential solution that addresses the need for multiple modelers working within WhereScape RED, and not overlapping work.
Cheers,
Peter
As far as I am aware, RED doesn’t have source control that prevents this sort of collision. The closest that I can recommend is (as you have done) make sure your team is communicating when anyone is touching the model, and also make sure you have set RED to use a centralised database for storing it’s model (so that changes are propagated immediately).
Another possibility could be to have stand-alone RED instances, and force the engineers to export the model as XML, then source control that. Then a central version of RED can import the model and push that to your DB.
1 Like
Hello, I have’t touched RED is years but doesn’t it have a set up process to set up a shared repository? Derby DB or something like that?
Hello health-sats!
In my oppinion Wherescape should prevent collisions, it does not. I worked with a client that faced the same issue when they used Wherescape. I guess you could GIT the .vst-files and run different instances of Wherescape but that will be very costly due to their licence agreement. Problem with the .vst’s are that they are generated by Wherescape and it is hard for a human to see the changes from one vst-version to another, its like when you version control SSIS packages, a nightmare!