TcaplusDB OMS Console - Modify a Table
1. Function Descriptions
After creating a table, you can choose to modify it.
Notations for modifying/rebuilding a table:
After modifying the table on the server, the table structure on the client needs to be updated (the table structure of the TDR table and the PB table needs to be regenerated, and the client link needs to be restarted)
2. Steps
App Maintenance - Table Management - Select the table to be modified. You can modify a single table or multiple tables
Enter the table modifying page, upload a new table definition file, or select the uploaded table definition to modify
3. Notations
Modify a PB table
(1) The primarykey field cannot be deleted.
(2) The primarykey field name and field type cannot be modified.
(3) The primarykey field cannot be added.
(4) Regular fields with the required ID cannot be deleted.
(5) Field names and field types with the same ID cannot be modified.
(6) The added regular field names should conform to the name rules.
Modify a TDR table
(1) Duplicate field names are not allowed in a table. The Key field name, Value field name, Value field name and Key field name must not be duplicates.
(2) The value of the primarykey in the tdr meta definition (that is, the key field name) must belong to the existing field name, and the value of the splittablekey must belong to the existing primarykey value (that is, the Key field name). Note: The primarykey defines the Key field.
(3) It is not allowed to delete the Key field, add the Key field, or modify the Key field type. The length of the Key field cannot be modified. It is not allowed to configure the default value for the Key field.
(4) It is allowed to add a Value field and modify the default value of the Value field. It is not allowed to delete the Value field and modify the Value field type. The maximum length of the Value field can be lengthened but not shortened. The default value of the Value field can be modified, but the actual length of the default Value cannot exceed the maximum length of the Value field.
(5) The Index field must belong to the name of the existing Key field, the Index field must contain the field specified by splittablekey, and all the Index fields must belong to the primarykey.
(6) It is not allowed to duplicate field names in the Index field. The length of the column attribute of the Index field cannot exceed 120 bytes.
(7) It is not allowed for the Index field to be configured for a List table.
(8) The maximum number of LIST elements in a List type table can be increased, but not decreased. At the same time, the maximum number of LIST elements in a List type table cannot exceed 10000.
(9) The number of indexes and the field names included in the index cannot be modified.
(10) The version of tcapsvrs where the table is located should be higher than 3.13.0.115217 to modify the "maximum number of LIST elements".
(11) Current TDR limitations: The key field name and the value field name cannot be modified.
(12) If count is defined for a new added field, but refer is not defined, it is not allowed to be modified
(13) The maximum number of entry fields in the tcaplus table is 256. When the number reaches 110, there will be a warning prompt. The maximum number of values in the list type table should be reduced by 1.
(14)Regarding changes to the TDR table (adding new columns), the situation where business instances using old versions of TDR information are read and then updated and written:
- If a new first level field Data1 is added to the table, it will be merged on the server side; That is, client1 writes Data and Data1 fields, while client2 is still an old table structure that only recognizes the Data field and updates it. On the Tcaplus server, the updated Data and Data1 will be merged, and the first level field will retain higher versions of data.
- If a new secondary field Data1 is added to the Data field in the table, the modifications to the Data field will overlap with each other. The reason is that the secondary field Tcaplus has not been parsed and is directly overwritten with the results from the client.
- For the PB table, if all records are updated, it means the entire record is overwritten; If it is a partial field update, only the specified fields will be updated, and the values of other fields will remain unchanged, but the overall record version will be increased by 1
4.Compatibility Statement for Table Changes
TcaplusDB allows users to perform table change operations online. At this time, there may be issues with both new and old clients reading and writing data at the same time. Therefore, compatibility of data reading and writing needs to be considered
For TDR tables:
(1) If a first level field is added: if a new client writes this first level field, the old client will not read it, and Tcapsvr will retain it; If the old client writes without this first level field, Tcapsvr will not delete the stored new first level field and will keep it
(2) If the first level field is modified: since both the key and value fields cannot modify the data type, there is only a scenario where the first level field array becomes longer. If the old client reads an excessively long array written by the new client, the old client will truncate it based on the local array size
(3) If nested fields are modified and the first level fields remain unchanged: both new and old clients read and write the same records. Since Tcapsvr storage is encoded based on the first level fields, the content of the first level fields will overlap with each other. The compatibility of user data reading depends on TDR's unpacking compatibility (TDR's higher version meta can unpack lower version data, while lower version meta unpacking higher version data may cause confusion)
For PB tables, since the update of PB involves packaging the entire message as a value and writing it, the backend writes the content of the user's entire message after packaging it. When both new and old clients update this record simultaneously:
(1) The data written by higher version clients, unpacked by lower version clients to msgs, and newly added fields will be retained by protobuf in unknown fields. When lower version clients set to tcaplus, if they do not actively clean up unknown fields, the new data will be retained and sent to the server for direct storage, which is manifested as merging semantics from the client's perspective.
(2) When the data written by a higher version client and unpacked by a lower version client to an MSG is actively cleared of unknown fields, or when the user copies fields from the MSG to another new MSG, and finally writes the new MSG to tcaplus, the newly added fields do not exist, and from the customer's perspective, they appear to overwrite semantics
5. Related Documents
In addition to modifying tables through the OMS console, users can also Modify a Table by calling the WebService API. The WebService API is mainly used in scenarios where tables need to be modified automatically through code.