Datastax QueryBuilder - Counting Truncate Records

[Dom Garda]

I am using com.datastax.driver.core package to write records to Cassandra. I have some code that uses the Truncate method / class to remove all records from a table.

Is there a way to count the amount of records that were deleted from the result set or is this impossible?

Truncate truncateQuery = QueryBuilder.truncate(TABLE_

NAME);

        truncateQuery .setConsistencyLevel(ConsistencyLevel.QUORUM);

        ResultSet deleteResults = pool.getConnection().execute(truncateQuery );

Currently I am only checking if the execution was applied.

ResultSet deleteResults = this.pool.getConnection().execute(truncateSomeStuff);
return deleteResults.wasApplied();

[Alexandre Dutra]

Hello Dom,

I'm afraid there is no way to find out how many records have been deleted as this information is not returned by Cassandra to clients.

Also note that checking ResulSet.wasApplied() does NOT make sense for a TRUNCATE statement (it will always return true). This method only makes sense for conditional updates.

Hope that helps,

Alexandre

--
You received this message because you are subscribed to the Google Groups "DataStax Java Driver for Apache Cassandra User Mailing List" group.
To unsubscribe from this group and stop receiving emails from it, send an email to java-driver-us...@lists.datastax.com.

--

Alexandre Dutra

Driver & Tools Engineer @ DataStax

[Dom Garda]

Is there anything in the ResultSet from a Truncation query that indicates success?

[Andrew Tolbert]

Is there anything in the ResultSet from a Truncation query that indicates success?

Unless I am mistaken, if you get a ResultSet back from C* (and not an exception thrown) that should be enough indication that the truncate has completed successfully.

Thanks,

Andy 

[Jack Krupansky]

Maybe the real question is whether there is a super-efficient way to count how many rows are in a table. For a small, single-node database a SELECT COUNT(*) does the trick, but for a large table on a large cluster, what is recommended (besides... don't do it!)?

The whole point of TRUNCATE is that it is super-efficient and doesn't involve any row at a time work since it is simply removing the sstable files themselves (after performing a snapshot.)

Is you use case for a relatively small table? If so, simply do that SELECT COUNT(*) before the TRUNCATE and be sure to set the LIMIT high enough to encompass your entire database.

Otherwise, if you really have to do this, you could do a nodetool cfstats for each node and approximate the number of rows from the amount of data in the sstables and memtables.

Or, maybe... you just want to know if SOMETHING was deleted or whether the amount deleted was small or below or above some threshold? If so, you could still do that SELECT COUNT(*) with a reasonable low LIMIT or even the default LIMIT of 10000, which would at least tell you whether you had that minimum number of rows before you proceed to TRUNCATE.

FWIW, do an experiment - do the SELECT COUNT(*) immediately after issuing the TRUNCATE and see whether it actually comes back with zero and how quickly it returns.

-- Jack Krupansky

[Dom Garda]

I was/am just a little confused when writing some unit tests that did truncation about what could I assert was true about the result set afterwards. :)

I can run a count before and after, but it seemed sort of sloppy to validate like that and was hoping something in the ResultSet would indicate success (maybe just not throwing an exception in this case?).

Thanks for the replies!