Is the ThingWorx database backwards-compatible?

[rwiseman]

If not, an alternative question is:

"Is the ThingWorx version number stored in the database?"

If not, what happens if an older instance of ThingWorx connects to the database?  Will it still work properly?  Can/does ThingWorx check that the database schema looks OK?  If not, is that something I can do manually?

[ttielebein]

If you are within the same version and it is just a service pack difference, then that is probably compatible. I have definitely run into errors when trying to deploy an older version of ThingWorx without first deleting my storage folders when a new version had been deployed (e.g. if I am deploying 6.5 after 7.2 was already deployed). What exactly are you trying to do that you are asking about this?

[rwiseman]

Hi Tori,

Thanks for the response.

I have a VM template for people to spin up their ThingWorx instance and a separate database server.  When someone spins up an instance of ThingWorx they get a database schema of the corresponding version.  If I then update the template to a newer (not just service pack) version, their database will need to be upgraded if they then spin up a new instance of ThingWorx (which connects to their existing database).  And if they then (accidentally, presumably!) go back to using their old version of the ThingWorx VM after having upgraded their database, then the database will be a newer schema version than the server.

I've currently implemented something that doesn't allow the user to get as far as starting their ThingWorx instance if its major and minor version numbers don't match those of their existing database.  That should catch most mismatch cases.

Regarding storage folders, I never quite understand their purpose...  Are these a local cache of some kind?  Do they merely reflect the database rather than somehow augment it?  Can they safely be deleted without impacting ThingWorx?

Thanks,

Richard

[ttielebein]

In Postgres, you can delete the storage folders with little impact on the entities and data found within composer, but anything contained within file repositories will be deleted, any extensions will need to be re-imported (and not doing so before trying to load the entities on the server may cause issues), and any logs, reports, or custom certificates will be deleted as well. In Neo instances, the full database will also be wiped and all entities and data will be lost if the ThingworxStorage folder is deleted.

There is not a ton of documentation on this, but I did find some mention of it in the Help Center. In all honesty, great care should be taken when modifying these folders for any reason. A backup should always be taken before any upgrades or migrations.

The safety precautions you are putting in place to stop people from spinning up an older Platform version while the database version is newer should be sufficient.

[rwiseman]

Thanks Tori.

Unfortunately it's beginning to look like my safety precautions aren't enough after all.  I don't know why, but when I run the migration scripts, it doesn't update the version number in the database.  I'm sure it did the first time I ran them, since that database contains the correct values (indicating v7.2.5) but having run the scripts on another two databases, I've noticed that they're both still showing as v7.0.0.

The SQL I'm running is: SELECT major_version, minor_version, revision FROM public.system_version;

I'll have to go back and check the process I used previously in case I missed a step.  I definitely ran (without error) the 7.0 to 7.1 and 7.1 to 7.2 scripts though... :-/

[rwiseman]

Hmm, so further investigation shows that the version number doesn't actually get updated until tomcat is running.  So (for now at least) I'll have to hack the database to make it look like the version number is correct, then start tomcat (which will add a row to the database with the correct version number) and then re-hack the database to revert the hacked bit!  Not very nice. :-(

[ttielebein]

That is a bit messy! I am glad you got this working though