Bumping this thread because we’re hitting the problem too. +1 for set-delete.
Is there a set-deletion feature on the road map? We have an elegant/clean/efficient design which we can’t use until there is a way to drop a set completely (the set’s existence; not just its contents).
Heads up here. Aerospike is such a cool product but lack of a set removal via an api makes it super hard to use in our project. Any plans to release it in the near future? If a set can be created via an api then it should be trivial to drop it
Thanks
Yes, this has been introduced in Aerospike 3.12.
Here is the java documentation: http://www.aerospike.com/apidocs/java/com/aerospike/client/AerospikeClient.html and scroll down to the “truncate” method.
You now has it, as of Aerospike 3.12.
There is also API support available in all the languages.
As of Aerospike 3.12 , namespace and set deletion is now supported with a single, fast command - truncate.
@bbulkow Thanks for the heads up!
The docs for truncate don’t say anything about the set itself being deleted, but only its contents. Can you confirm whether the set itself is removed, or whether only its contents are? Thanks.
Only its contents are, but for the Enterprise Edition, given that the deletes are durable, a rolling cold start would take care of removing the set itself.
In Aerospike, the set will show up in the metadata ( vinfo table ) until a cold restart. If you cold restart, and there are no records in the set, then the vinfo table entry is not created. The vinfo table is the source of the 1024 limit, so if you’re talking about how to break the vinfo limit, this doesn’t do it.
With CE builds, truncate is not persistent ( just like deletes ), so a cold restart may bring parts of the set back. There is no easy way to avoid this.
With EE, a rolling cold restart will reclaim the slots.
The ability to have Truncate reclaim vinfo slots and thus break the 1024 limit is on our list for future release, but will not be immediate.