Oh, I thought it was a tool that could be used by anybody to test / verify (as in validate, not the verify command) the event store.
Well in this case, I ran verify thinking it would check the data that was inside the event store (kind of like a checkdb) but it actually creates fake banking data. But I have no clue how the parameters are linked to one another since using the default it created about 5 million events which corresponds to no combination of: writes operand events operand streams
So we get something like:
WR => writes something to a stream. Though I have no idea on how to give it the data it wants at this time.
WRJ => best guess is that it requires JSON and it is a write json to a specific stream
WRFL => Writes flood: Writes events to streams does not wait for the flush to disk
WRFLCA => no clue what the CA stands for
WRFLW => Writes flood and wait for the flush to disk for each event
MWR => Memory Writes for when the event store runs as mem db is my guess
MWRFLW => Memory writes flood and wait for flush to memory when the event store runs as mem db is my guess
TWR => Writes to a specific thread is my guess
RDALL => read all
RD => Read from a stream
RDFL => read flood
WRLT => Writes on a timer is my guess
VERIFY => Creates fake banking data, around 5 million events i think
SCAVENGE => Scavenge, but what, I got no clue. Or maybe it is just a purge for everything that is defined as being ‘old’ via the ‘max’ metadata of the streams
SUBSCR => Subscribe to streams
CHKTCP => Check TCP, but no clue what it does. Open the tcp port to see if it communicates ? Considering the bugs / issues I sometimes have with the event store I have a feeling that one does not work properly. IE: If I run RDFL or WRFL while one of our dev runs a read test from the application I can actually get disconnected from the Event Store or I also get a lot of fails on writing data. Concurrent connections don’t seem to be appreciated at all. And I end up with a TCP handle error.
And I have no clue what these do especially when seeing the parameters:
And USAGE seems to do the same thing as HELP
Also some of the parameters befuddle me like commit position and prepare position on the read all call.