Hi Cheongu, This should be a bug and may be already fixed in v1.3.0, you can try with V1.3.0 again. If you can replay this again in V1.3.0, can you give us a complete replay way? like your sample data and ingestion program.
Best regards, ------------------------ Yuan Tian On Mon, Apr 8, 2024 at 5:26 PM 김천구 <[email protected]> wrote: > Hi all, > > I'm currently using version 1.2.2 of IoTDB, it seems like there might be > an issue with a data insertion in IoTDB. > > Previously, I have loaded a public dataset into IoTDB that contains > duplicate records for time. > I have observed data loss occurring for duplicate timestamps, which is > expected. However, I have discovered something strange. > > IoTDB> select * from root.Chicago.** where time = 1433123100000 > > +------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ > | Time| > > > root.Chicago.taxi.value| > > +------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ > |2015-06-01T10:45:00.000+09:00| {'vendor_name' > : Blue Diamond, 'location.type' : Point, 'location.latitude' : > 41.880994471,'location.longitude' : -87.632746489}| > |2015-06-01T10:45:00.000+09:00| {'vendor_name' : Blue Ribbon Taxi > Association Inc., 'location.type' : Point, 'location.latitude' : > 41.97907082,'location.longitude' : -87.903039661}| > > +------------------------------------------+---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+ > Total line number = 2 > It costs 0.085s > > Looking at the results above, even though the timestamps are identical, > there are two tuples inserted. How can two tuples be stored at the same > time? Since both are referencing the same time series, shouldn't one value > overwrite the other? > Could you explain why such a situation occurred? > > Cheongu Kim >
