cancel
Showing results for 
Search instead for 
Did you mean: 
RADSr
Captain
Captain
Status: Prioritized

I'm about to embark on a major change to a schema.  I need to keep the current "gold" copy intact while I work on this change. 

AFAIK, the process I need to use currently is:

 

1)    Create new schema 

2)    Export new schema

     - find it's ID number in the XML

2)    Export existing schema

   - replace the existing schema ID number with the new one

3)    Rezip existing schema and import

 

What would be better would to be able to make a copy similarly to the way I can make a copy of a dashboard and have Incorta take care of the new ID rather than opening up the process to user error. 

10 Comments
RADSr
Captain
Captain

Here's another use case for allowing this - I need to create some IA tables from a schema but I can't because the main fact table has a runtime security filter associated with it.   

The quick and easy answer would be to copy the schema, remove the filter on the new copy, create the IA tables and then apply the filter there for use in insights.

I *can* do that by doing a bunch of XML editing, but it goes from a quick and easy answer to a last-ditch, PITA answer which relies on manual edits to XML files and introduces risk of corrupting existing work.  

DustinB
Employee
Employee

@RADSr - For now, you could copy the fact table by creating an MV (select * from fact) and create your Incorta tables from that. Assuming your original fact table is an extract from the source, this has the added benefit of not re-extracting data that is already present. 

RADSr
Captain
Captain

That's a good idea and I may go that way, I still need to recreate all the joins but select * w/ Postgres SQL should bring in the formula columns so that will save a bit of time.   Probably be easier and less risky than the XML route.    Thx! 

RADSr
Captain
Captain

Lack of this feature has cost me the entire day.

I backed up, made changes which required full loads of some tables.  Many confusing errors and an entire day of data not being accessible to users and I'll wind up restoring from this morning's backup.   

Tomorrow, I'll have to restore from EOD today ( the copy I'm working on ) which will once again require full loads rendering that time gone. 

EOD tomorrow I'll either have a solution in place and hope the limited testing window is enough or have to repeat the process. 

Let's bump this up the roadmap!

 

Status changed to: Accepted
awarrier
Employee
Employee

Making a copy for a business schema will be prioritized and will be available in an upcoming release in the next 2-3 months.

 

Adetweiler
Astronaut

Copying the physical schema is a great idea.

zjuneau
Ranger

Really need this to be implemented

Status changed to: Prioritized
awarrier
Employee
Employee
 
dylanwan
Employee
Employee

Manually editing the schema XML files may result in a corrupted Incorta metadata and can cause the entire system not workable.  Even a small typo with the schema name, which can be sensitive, caused us a lot of time to debug as the symptom is on the model sync failure and we don't expect the model to be inconsistent.

Manually editing XML files is not a supported option and we should avoid doing it.  

RADSr
Captain
Captain

I don't disagree @dylanwan  - but lacking a good UI option, it's the tool I have ( "had" I'm hopeful soon! )