[Fix]: fix TAG type mismatch by introducing schema version for TDengine

[Saramanda9988]

What's changed?

Please refer to #3961

This PR resolves the issue where the monitor TAG was incorrectly defined as BIGINT in v1.8.0, causing insertion failures for string-based instance

1. appended a _v2 suffix to both Super Table and Sub-table names (e.g., ..._super_v2). This bypasses TDengine's limitation where TAG column types cannot be modified after table creation.
2. Updated monitor TAG type to NCHAR(128) in the new v2 schema.

Checklist

• I have read the Contributing Guide
• I have written the necessary doc or comment.
• I have added the necessary unit tests and all cases have passed.

Add or update API

• I have added the necessary e2e tests and all cases have passed.

[Duansg]

Doesn't Prometheus's task need to be handled?

[Saramanda9988]

Hi @Duansg ,

Are you referring to the table name mismatch issue caused by users modifying the monitor name of Prometheus tasks?
If so, I find that this problem also exists in IotDB, QuestDB, and InfluxDB, but not in GreptimeDB (which only uses metrics) and VictoriaMetrics (which uses labels)



Perhaps we should address these related issues separately through a dedicated PR? This PR can focus on fixing TDengine's TAG issue.

Please let me know if I understood your concern correctly or you'd like me to fix TDengine's related issue just in this issue.

[Duansg]

Are you referring to the table name mismatch issue caused by users modifying the monitor name of Prometheus tasks?

That's correct, this is a historical issue, not caused by the instance reconstruction. I've reviewed the relevant logic and found it's not straightforward. Even a simple modification to ensure compatibility would require extensive regression testing on other dependent features. To ensure the issue remains traceable, I'll create a new PR to address this later.

[Saramanda9988]

Are you referring to the table name mismatch issue caused by users modifying the monitor name of Prometheus tasks?

That's correct, this is a historical issue, not caused by the instance reconstruction. I've reviewed the relevant logic and found it's not straightforward. Even a simple modification to ensure compatibility would require extensive regression testing on other dependent features. To ensure the issue remains traceable, I'll create a new PR to address this later.

OK,thanks
If needed, I’m happy to help with some testing for that.

[Duansg]

Are you referring to the table name mismatch issue caused by users modifying the monitor name of Prometheus tasks?

That's correct, this is a historical issue, not caused by the instance reconstruction. I've reviewed the relevant logic and found it's not straightforward. Even a simple modification to ensure compatibility would require extensive regression testing on other dependent features. To ensure the issue remains traceable, I'll create a new PR to address this later.

OK,thanks If needed, I’m happy to help with some testing for that.

👍🏿 ok, i suggest you reproduce the issue and file a ticket so we can track it :)