gRPC inserting with incorrect affected row about greptimedb HOT 5 CLOSED

This is a good point... But I can explain why it's 10000 in two aspects

• The 10000 inserted rows are treated as 10000 independent data, and those duplicates can be seen as "update" to the previous one
• The dedup process is done on reading. Those 10000 rows are persisted to file in actual.

from greptimedb.

One possible reason is duplicated rows. Our DB will automatically remove duplication (iff time index + primary key are the same) on read.

from greptimedb.

One possible reason is duplicated rows. Our DB will automatically remove duplication (iff time index + primary key are the same) on read.

Yes, but the affected rows in response SHOULD NOT be 10,000, it SHOULD BE the actual affected number of rows

from greptimedb.

It's not recommended to rely on the value of affected rows. Sometimes it's hard to get the correct affected rows (e.g. DELETE). We return it because some SQL protocols need this.

In your case, rows with the same key are actually inserted twice and the row being overwritten is also "affected". Since our INSERT operation is actually a PUT operation in some NoSQL dbs.

To see whether an insert request is executed successfully, checking the response code is enough.

from greptimedb.

This is not a bug, but a workaround solution, and DO NOT rely on the affected row.

from greptimedb.