Skip to main content
16-Pearl
January 28, 2020
Solved

Solve export/import property overwrite

  • January 28, 2020
  • 2 replies
  • 3095 views

I use some things as a library container for some specific functions

On those things I have services and properties.

 

I also have sandbox and production cloud hosted instances.

 

I develop on sandbox then export to production when all is OK ... as all probably do 😉

The problem is that properties contain "local parameters" and the values are different between sandbox and production.

So ...if I export from sandbox and import to production, I could overwrite the right production properties values !

Note that this overwrite may happen also if I export a thing now "as a backup", and import it again after some time

 

What is the best way to avoid this ?

 

  • May be I could work with thingshape instead of writing directly on the "Library thing" (and export-import the shape instead of the thing ), but this will make a little more complicated and unnecessary for a single thing (shapes are useful for usage on many things).
  • Or I could bind properties of the "library thing" to another thing ... don't know however what happen with bound properties values after export-import of the "library thing"
  • or use a datatable for storing values ....

 

It would be helpful to avoid overwrites ... a checkbox "skip import value" for each property (on the Aspects section) that will avoid the overwrite of the value during an import procedure.

Best answer by iguerra

I solve now the problem as on my first post

I implement in this way:

  • I have the Thing instance, eg. MyLibrary
  • I have also a thing shape, eg MyLibrary_TS. 
    MyLibrary thing uses MyLibrary_TS as Thing shape

when I work on sandbox and I add or change properties/services I work on the ThingShape, and I export to production just the TS ... not the thing instance ... so the production "local" thing properties are preserved after the import procedure.

2 replies

Support
January 28, 2020

Hi @iguerra.

 

A couple of possible solutions:

 

  1. You could use tags/projects to filter the entities for export/import
  2. You could store the environmental values in a data table for update after completing a migration

Regards.

 

--Sharon

iguerra16-PearlAuthor
16-Pearl
January 29, 2020
  1. I frequently use tags to export just some objects, this just to create a "block" and export in a single operation many objects. But this will not avoid property overwrite when importing those objects on the target application.
  2. which enviromental values ? My problem is with things properties ...
    I wasn't speaking of a whole migration/cloning from sandbox to production ... I never made this. But just export-import of a module or some things for an update.

 

 

Support
January 30, 2020

Hi @iguerra.

 

I wasn't referring to cloning either--just a migration of specific entities from one environment to another.  Can you give us some examples of the property values for local parameters that should not be overwritten?  We assumed these were environmental parameters (prod, dev, sandbox, etc.). If so, storing these values in a data table for update after completing an export/import process, may be the best solution.

 

In regard to your suggestion for a checkbox to "skip import value" for a property, I see that you have already posted your suggestion on the ThingWorx Ideas board.  With enough votes, your idea may be considered for a future release.

 

Regards.

 

--Sharon

iguerra16-PearlAuthor
16-Pearl
January 31, 2020

Hi Sharon

I may have just as example, a datatable with local properties, a counter (used as incremental key for adding entries) , or a infotable property to contain some user data ... or statistics for example.

This structure is the same on sand and production, but they have different values.

 

If I export this datatable from sand (not the data ..just the thing because I updated something like adding new property or updated a local service) and import into production, the production will get the property values of sandbox, causing possible errors or other effects.

 

Support
February 3, 2020

Hi @iguerra.

 

Hopefully some of the Developers in the community can respond to this with suggestions.  At a minimum, however, you need to identify which properties vary between environments and determine the best method for update following your import.  This could include many possibilities, such as manual updates, REST services for updating the appropriate values, or as initially suggested, a data table in each environment containing the relevant values.

 

Regards.

 

--Sharon