0

Copy a schema to another *and* move from environment 1 to environment 2

As in the title, I have a schema developed in an environment - let's call it "PROD" and I want to 1) do some major work on it, integrating in new tables and logic while leaving the existing in place for business use, so 2) make a working copy of it so I can work on it without impacting the business, and 3) do my work in DEV, because DEV is where DEV should take place ( don't @ me!  ;-)  ) 

 

Thus far I've

Created a placeholder schema _RAD_Testing in DEV and gotten the ID from it.

Exported the PROD version

    Changed the ID from the PROD ID to the DEV ID of _RAD_Testing

    Changed anything qualified with <orig>. to _RAD_Testing. 

    Changed the name and schema name in the loader file ( "?><loader name="_RAD_Testing" schema="_RAD_Testing" )

    ** Not sure what the xml:base=  value should be - kind of guessing my _RAD_Testing schema ID_Loader  and schemas/<new ID>_schema.xml ?

 

Saved the edited PROD files, ZIPPED, and attempted to import into DEV and  ....   didn't work.    My _RAD_Testing looks just the way it did before and the original name schema threw all kinds of errors trying to commit which isn't surprising given all the changes I did.

 

Is there a documented process for this kind of task?  And/or what (obvious?)  thing am I overlooking?  

5replies Oldest first
  • Oldest first
  • Newest first
  • Active threads
  • Popular
  • Hi R. A. Dawson Sr I'm a little confused by your use case. If you are following our recommended best practice for Dev/Prod environments (Software Development Life Cycle), you would already have a copy of the PROD schema in DEV and that's the schema you should leverage for further development. Once complete and tested, you export from Dev and import that schema into PROD. If for some reason the schema does not exist in DEV, simply export from PROD and import into DEV directly. You really should avoid manual manipulation of XML. While there may be cases that require it, I'm not seeing a reason in this scenario. Apologies if I'm missing your point!

    Like
    • Dustin Basil 

       

      Ha!  I'm with you and I advocate and follow that best practice, but the world simply will not listen to us!

      In this case a developer built a schema in DEV and migrated to PROD.   An analyst then made changes to the schema in PROD making that different than the one in DEV so one step is to conform those.  That's an easy export => import.

      The second step is - I think -  more common need.  I need to make a copy of the schema so I can integrate some new tables, adjust the join structure, etc.  I need to do this without disrupting the use of the current copy.  So when I load the schema it doesn't mess up other concurrent development.

      That second bit is where I'm manually manipulating the XML - I want to make a copy of the schema, a copy of the business schema referencing  and existing dashboard - the schema has to be named differently so the business schema and dashboard references need to be adjusted accordingly.  

      BTW - I'm lobbying for votes ( https://community.incorta.com/t/x2hjx1p/allow-developers-to-copy-a-schema )

      Even if I could copy the schema I'd still have to be able to copy the business schema and change the qualifiers and then a copy of a dashboard to reference the new business schema.

       

      TL/DR - I need a copy of objects to do development work in parallel.  ( should have started w/ that  ;-)  ) 

      Like
    • R. A. Dawson Sr It seems that what we need is to support different schema versions of a schema which are under development.  One published version that can be used for loading data but other versions can be saved and published when it is ready?  The trick seems that an under developing dashboard can point to an under developing business schema, which can point to an under developing physical schema?

      Like
    • Dylan Wan  Yes - so it breaks into two things 1) ability to create a copy of an object  ( ideally from table/view up through schema or business schema ) and 2) the ability to point an object ( or copy of an object ) at a different underlying source.

      Like
    • R. A. Dawson Sr I mean that the created is not a duplicate or a separate object (with different GUID), but actually the same object with different versions and we need the ability to apply a given version to replace the current active one. 
      We introduce the Draft mode in schema designer - https://docs.incorta.com/5.1/tools-schema-designer/. It can support one active and one draft mode.

      For the second point, dashboards and business schemas have no materialized data so the different version may coexist in a runtime env, but it will be harder for physical schema as the data has to be loaded.  

      Like
Like Follow
  • 1 mth agoLast active
  • 5Replies
  • 28Views
  • 3 Following

Product Announcement

A new community experience is coming! If you would like to have beta access to provide feedback, please contact us at community@incorta.com.