[Bug] Meet error when insert csv because 507: Fail to insert measurements [in_time] caused by [data type of root.log.in.in_time is not consistent, registered type TIMESTAMP, inserting type FLOAT, timestamp 1737611978558, value 10.0]
- Vorherrschende Sprache
- Java
- Sterne
- 6.4k
- Forks
- 1.2k
- Ø Merge
- 1 T. 23 Std.
- Gemergte PRs (30 T.)
- 115
Beschreibung
### Search before asking
- [x] I searched in the [issues](https://github.com/apache/iotdb/issues) and found nothing similar.
### Version
dev-1.3 版本,2025-01-2217点拉取、编译生产的;
### Describe the bug and provide the minimal reproduce step
1. 首先我要导入一个表数据;
- 表结构如下:
```shell
IoTDB> show nodes in schema template test
+----------+---------+----------+-----------+
|ChildNodes| DataType| Encoding|Compression|
+----------+---------+----------+-----------+
| name| STRING|DICTIONARY| LZ4|
| in_time|TIMESTAMP| TS_2DIFF| LZ4|
| device_id| INT64| TS_2DIFF| LZ4|
| thresold| STRING|DICTIONARY| LZ4|
| value| STRING|DICTIONARY| LZ4|
+----------+---------+----------+-----------+
```
2. 然后需要从一个csv文件导入到表内
- csv 文件内的数据如下:
```csv
Time,Device,name,in_time,device_id,thresold,value
2025-01-23T14:08:38.558+08:00,root.log.in,"device_name1234567890",1737612237512,10000001,"1","value_test_111"
2025-01-23T14:07:38.558+08:00,root.log.in,"device_name1234567891",1737612237512,10000002,"2","value_test_112"
2025-01-23T14:06:38.558+08:00,root.log.in,"device_name1234567892",1737612237512,10000003,"3","value_test_113"
2025-01-23T14:05:38.558+08:00,root.log.in,"device_name1234567893",1737612237512,10000004,"4","value_test_114"
2025-01-23T14:04:38.558+08:00,root.log.in,"device_name1234567894",1737612237512,10000005,"5","value_test_115"
2025-01-23T14:03:38.558+08:00,root.log.in,"device_name1234567895",1737612237512,10000006,"6","value_test_116"
2025-01-23T14:02:38.558+08:00,root.log.in,"device_name1234567896",1737612237512,10000007,"7","value_test_117"
2025-01-23T14:01:38.558+08:00,root.log.in,"device_name1234567897",1737612237512,10000008,"8","value_test_118"
2025-01-23T14:00:38.558+08:00,root.log.in,"device_name1234567898",1737612237512,10000009,"9","value_test_119"
2025-01-23T13:59:38.558+08:00,root.log.in,"device_name1234567899",1737612237512,10000010,"10","value_test_120"
```
3. 再shell终端导入
```shell
root@IOT:/usr/local/iotdb/tools# ./import-data.sh -u root -pw '密码' -s /home/dump0_0.csv -aligned true -file_type csv -ty ms
Meet error when insert csv because 507: Fail to insert measurements [in_time] caused by [data type of root.log.in.in_time is not consistent, registered type TIMESTAMP, inserting type DOUBLE, timestamp 1737611978558, value 1.737612237512E12]
```
- 哦,对了,-file_type参数,不是type参数,使用type参数不行
4. 难道需要转换下格式?
```shell
# 加双引号报错:
Meet error when insert csv because 507: Fail to insert measurements [in_time] caused by [data type of root.log.in.in_time is not consistent, registered type TIMESTAMP, inserting type STRING, timestamp 1737611978558, value 1737612237512]
# 加单引号报错:
Meet error when insert csv because 507: Fail to insert measurements [in_time] caused by [data type of root.log.in.in_time is not consistent, registered type TIMESTAMP, inserting type STRING, timestamp 1737611978558, value '1737612237512']
# 使用date 报错:
Meet error when insert csv because 507: Fail to insert measurements [in_time] caused by [data type of root.log.in.in_time is not consistent, registered type TIMESTAMP, inserting type STRING, timestamp 1737611978558, value 2025-01-23T14:08:38.558]
```
### What did you expect to see?
# waiting
### What did you see instead?
# waiting
### Anything else?
# no
### Are you willing to submit a PR?
- [ ] I'm willing to submit a PR!
Beitragsleitfaden
Rechercherichtung
Reproduziere den Fehler mit tools/import-data.sh unter Verwendung des CSV-Befehls und der in der Issue gezeigten TIMESTAMP-Spalte. Verfolge den CSV-Importpfad ausgehend von diesem Skript und untersuche, wie die Option -ty ms numerische Zeitstempelwerte im Vergleich zu TIMESTAMP-Schemafeldern parst. Als erledigt gilt die Aufgabe, wenn der Beispiel-CSV-Import ohne einen Typkonfliktfehler erfolgreich ist und die vorgesehenen Zeitstempelwerte erhalten bleiben.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Bewertung
- Tech-Stack
- bash, java
- Bereich
- databases
- Issue-Typ
- Bug
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Aktivitätsstatus
- Veraltet
- Klarheit
- Größtenteils klar
- Anfängerfreundlichkeit
- 25/100