Deleting all data from an EventStore via HTTP requests

Hi,

I would like to delete all data from an Event Store via HTTP requests to subsequently create a fresh set of test events without compromising the streams I am deleting.

If I have a stream such as MyEvent-1, and want to delete it using curl request: curl -v -X DELETE http://eventstoreURI:2113/streams/MyEvent-1 -H “ES-HardDelete:true” then I can’t create another event with the same name.

By the way, I don’t have the option of deleting all the data on the hard disk from the Event Store in this instance.

Any ideas?

Kind regards,

Mark

Hi Mark,
You probably don’t want to perform a hard delete. This basically means that the stream will never be able to be written to again. You want to perform a soft delete, but this is also not the same as having a clean database.

For instance, the event numbers for a soft deleted stream are preserved and the way the delete works is basically by the use of metadata for a stream. When you soft delete a stream, Event Store adds a truncate before metadata event in the metadata stream for the stream you are performing the delete on.

If you want to reclaim the disk space for the deleted streams you would also then have to perform a scavenge. The scavenge will only affect completed chunks.

Well you could softdelete which is kind of the point of softdeleteing
(that you can recreate it).

Hi Pieter,

Thank you for the response. I think now I’ve seen your response I’ve realised that maybe I was meant to ask a slightly different question… I want to be able to start from Event 0 and add a new set of test data without actually cleaning the database.

So I’d want to:

  • Delete all streams.

  • Start from Event 0.

It doesn’t sound like this is possible without physically accessing the database and deleting the data itself from the EventStore ?

Kind regards,

Mark

This would break caching models.

Can’t you run GES with InMemory storage iso writing to disk? If you don’t care about the data this might be a viable option

Ah OK. That makes sense.

Thanks for the response Greg,

Kind regards,

Mark