What Happens in the Database when Changing Type Name, Schema Name, and Field Names on a Type?

#1

It’d be interesting to know more about each of the following scenarios, and how they are handled in the backend. Please correct any misunderstandings below, and elaborate on any incomplete scenarios:

Let’s start with a tag that has this TypeA.c3typ file provisioned and TypeA contains at least 1 row of data, representing a TypeA instance:

entity type TypeA schema name "TYPEA" {
  // id: string // inherited from Persistable, as are several other fields and methods.
  fieldA: string
  fieldB: decimal
  method1: <<some function>> js server
}

Scenario 1: Remove the TypeA.c3typ from the repository and provision.
Outcome: The TYPEA schema still exists in the backend (unless there was a script run that explicitly drops the underlying table). The data still exists in the backend (unless there was a script run that removes the data from the type before the type was removed). There is no longer any explicit Type-System support way to communicate with TypeA, however, so c3ShowType(TypeA) and TypeA.method1() will throw an error that TypeA is undefined.

Scenario 1a: Add the TypeA.c3typ back to the repository and provision.
Outcome: Since the schema was unchanged, the data was unremoved, and TypeA now exists again in the metadata, you can now interact with TypeA as usual.

Scenario 2: change fieldA name to fieldA_New and provision
Outcome: In the schema/underlying table, fieldA column still exists, and all existing data is still persisted. Any code (app logic/data integration/etc.) that refers to fieldA through the type system will return an error saying that the field is not defined. fieldA_New will be a new column in the table, and it will contain no data (unless a script is run to migrate the data from fieldA upon provisioning, or both fields exist for a brief period of time in a series of provisionings where a migration is run).

Scenario 2a: add fieldA back to TypeA and provision.
Outcome: fieldA column always existed, and all existing data is still present and accessible as before. fieldA can now again be referred to through any code in the AI Suite.

Scenario 3: Change the Type name to TypeANew and provision.
Outcome: TypeA is no longer accessible through the type system. !!!Question!!! I am unsure about what happens here to the existing data

Scenario 4: Change the schema name to TYPEA_NEW and provision.
Outcome: TypeA will still be accessible through the type system. !!!Question!!! I am unsure about what happens here to the existing data.

Scenario 5: Change the Type name to TypeANew and the schema name to TYPEA_NEW and provision.
Outcome: You’ve just created a full new type. TypeA no longer exists and cannot be referenced as a Type in the code. The schema TYPEA still exists in the backend, and data is still present (unless a script was run). TypeANew and its schema are also, of course, created and accessible through the type system, though they contain no data until populated by some process/app logic.

4 Likes

#2

For scenario 3, assuming that the schema name remains the same in TypeANew as it was in TypeA, then all data from the previous TypeA will be available through TypeANew If you also changed the schema name, then the original data for TypeA is untouched and new schema will be created for TypeANew based on the new schema name.

For scenario 4, changing the schema name will cause new schema to be created based on your new schema name and data for your tag will be copied from the old schema to the new schema.

1 Like

#3

Thanks, @trothwein, so in Scenario 4, the pre-existing data will exist in both TYPEA_NEW and TYPEA schemas, and after provisioning, TypeA will be ‘pointed to’ TYPEA_NEW schema.

0 Likes

#4

@ColumbusL, You are correct

0 Likes