backtick escape character handled inconsistently by CLI and Java API when create timeseries

I created TIMESERIES like this using the session.createTimeseries()

IoTDB> SHOW TIMESERIES
+--------------------------------------------------------------------------------------------------------------------------------------+--------+-------------+--------+--------+-----------+----+----------+
|                                                                                                                            timeseries|   alias|storage group|dataType|encoding|compression|tags|attributes|
+--------------------------------------------------------------------------------------------------------------------------------------+--------+-------------+--------+--------+-----------+----+----------+
|root.test.xx.xx.NULL.xx.ff8081816c21dc05016c22bdca284f65.CARD.CARD-8a5b8486656aa31001656b6d35d6768e.15.temperature||    root.test|  DOUBLE|   PLAIN|        LZO|null|      null|
+--------------------------------------------------------------------------------------------------------------------------------------+--------+-------------+--------+--------+-----------+----+----------+
Total line number = 1

You can notice that the path contains NULL

I get the following error when I delete it using the CLI

IoTDB> DELETE TIMESERIES root.test.xx.xx.NULL.xx.TRANS_ELEMENT-ff8081816c21dc05016c22bdca284f65.CARD.CARD-8a5b8486656aa31001656b6d35d6768e.15.temperature
Msg: 401: Error occurred while parsing SQL to physical plan: line 1:34 mismatched input 'NULL' expecting {CREATE, INSERT, UPDATE, DELETE, SELECT, SHOW, GRANT, INTO, SET, WHERE, FROM, TO, BY, DEVICE, CONFIGURATION, DESCRIBE, SLIMIT, LIMIT, UNLINK, OFFSET, SOFFSET, FILL, LINEAR, PREVIOUS, PREVIOUSUNTILLAST, METADATA, TIMESERIES, TIMESTAMP, PROPERTY, WITH, DATATYPE, COMPRESSOR, STORAGE, GROUP, LABEL, INT32, INT64, FLOAT, DOUBLE, BOOLEAN, TEXT, PLAIN, PLAIN_DICTIONARY, RLE, DIFF, TS_2DIFF, GORILLA, REGULAR, ADD, UPSERT, VALUES, NOW, LINK, INDEX, USING, TRACING, ON, OFF, SYSTEM, READONLY, WRITABLE, DROP, MERGE, LIST, USER, PRIVILEGES, ROLE, ALL, OF, ALTER, PASSWORD, REVOKE, LOAD, WATERMARK_EMBEDDING, UNSET, TTL, FLUSH, TASK, INFO, VERSION, REMOVE, MOVE, CHILD, PATHS, DEVICES, COUNT, NODES, LEVEL, MIN_TIME, MAX_TIME, MIN_VALUE, MAX_VALUE, AVG, FIRST_VALUE, SUM, LAST_VALUE, LAST, DISABLE, ALIGN, COMPRESSION, TIME, ATTRIBUTES, TAGS, RENAME, GLOBAL, FULL, CLEAR, CACHE, TRUE, FALSE, UNCOMPRESSED, SNAPPY, GZIP, LZ4, PARTITION, SNAPSHOT, FOR, SCHEMA, DESC, ASC, '*', OPERATOR_IN, '-', '[', INT, EXPONENT, DURATION, DATETIME, ID, DOUBLE_QUOTE_STRING_LITERAL}
IoTDB>

Desktop (please complete the following information):

• OS: MacOS
• Version 0.13.0-SNAPSHOT

How do I delete this TIMESERIES

[liuminghui233]

Hi,

I think the following syntax conventions should be followed in JAVA API:

• For IoTDB-SQL interface , such as executeQueryStatement and executeNonQueryStatement: The input SQL parameter needs to conform to the syntax conventions and be escaped for JAVA strings. For example, you need to add a backslash before the double-quotes. (That is: after JAVA escaping, it is consistent with the SQL statement executed on the command line.)
• For Other interfaces :
  • The node names in path or path prefix as parameter:
    • The node names which should be escaped by backticks (`) in the SQL statement, and escaping is not required here.
    • The node names enclosed in single or double quotes still need to be enclosed in single or double quotes and must be escaped for JAVA strings.
    • For the checkTimeseriesExists interface, since the IoTDB-SQL interface is called internally, the time-series pathname must be consistent with the SQL syntax conventions and be escaped for JAVA strings.
  • Identifiers (such as template names) as parameters: The identifiers which should be escaped by backticks (`) in the SQL statement, and escaping is not required here.

What do you think? Welcome to discuss if you have any concerns or ideas!

[jixuan1989]

@liuminghui233

For the checkTimeseriesExists interface, since the IoTDB-SQL interface is called internally, the time-series pathname must be consistent with the SQL syntax conventions and be escaped for JAVA strings.

This may cause some potential bugs: can we make sure all callers know the semantic?

For example, if someone implement a new Java interface like createTimeseries, and in the implementation, he/she calls checkTimeseriesExists… (Don’t we call checkTimeseriesExists in our createTimeseries method?)

Considering the above, I think adding a new function checkTimeseriesExistsWithSQL may be fine. @coolbeevip