[IOTDB-1983] Incorrect of deserializing DescReadWriteBatchData

• Type: Bug
• Status: Closed
• Priority: Major
• Resolution: Fixed
• Fix Version/s: master branch, 0.12.3
• Component/s: Core/Engine
• Labels: pull-request-available
• Assignee: Eric Pai
• Reporter: Eric Pai
• Created: 10/Nov/21 04:24
• Updated: 12/Nov/21 04:23
• Resolved: 12/Nov/21 04:22

Description

For example, If I initialize an INT64 type DescReadWriteBatchData, and put (time, value) like (3, 3), (2,2), (1,1) in descending order, the timeRet of this DescReadWriteBatchData is [...., 1,2,3] as our expected. But after serializing and deserializing by SerializeUtils, we get a new DescReadWriteBatchData which has the timeRet [..., 3,2,1], which is inconsistent with the original one.

It's bug actually, but I'm not sure the meaning of the index parameter of BatchData.getXXXByIndex. Is it the index of the data WRITE sequence, no matter what the batchDataType is?

The unit test codes here(you can put them into SerializeUtilsTest)

 

@Test
public void descReadWriteBatchDataSerializableTest() {
  DescReadWriteBatchData data = new DescReadWriteBatchData(TSDataType.INT64);
  data.putLong(3, 3L);
  data.putLong(2, 2L);
  data.putLong(1, 1L);

  ByteArrayOutputStream baos = new ByteArrayOutputStream();
  DataOutputStream outputStream = new DataOutputStream(baos);
  SerializeUtils.serializeBatchData(data, outputStream);
  ByteBuffer buffer = ByteBuffer.wrap(baos.toByteArray());
  BatchData data2 = SerializeUtils.deserializeBatchData(buffer);
  // In DescReadWriteBatchData, read has the same order with write
  Assert.assertTrue(data2 instanceof DescReadWriteBatchData);
  Assert.assertTrue(data2.hasCurrent());
  Assert.assertEquals(3L, data2.getLong());
  data2.next();
  Assert.assertTrue(data2.hasCurrent());
  Assert.assertEquals(2L, data2.getLong());
  data2.next();
  Assert.assertTrue(data2.hasCurrent());
  Assert.assertEquals(1L, data2.getLong());
  data2.next();
  Assert.assertFalse(data2.hasCurrent());
}

 

===========

After discussion, the getXXXByIndex() is clear: Get the ith element in the time ascending order. I will fix the bug and add unit test later.

 

 

 

Issue Links

• links to: GitHub Pull Request #4357
• links to: GitHub Pull Request #4361