Hi All,
Can someone tell me why when I delete a stream and then try and recreate the stream with the same name it throws an exception telling me it was deleted??
what am I missing?
cheers
Johnny
Actually it’s quite simple. The primary interface is atom over http, what happens with intermediary caching? We are working on allowing an override to this behaviour if you feel 100% sure it is safe.
In my case, allowing this would be great for local dev.
+1
ahh I see. Yea +1 for me to.
cheers
Johnny
If someone recreates a stream, then what about having a different name internally? Then when they go to the head link for that stream, first last etc just point somewhere else.
This is basically what’s been discussed.
I should add its a touch trickier than that 
as example head returns 502 when deleted and then there is scavenging.
coming back to this:
During development and/or QA we might accumulate quite a bit of data in GES. Our software is a complex enterprise app and certain features can only be tested when some complex boundary conditions are met. Thus it is not always easy to start with fresh data at any time, and specifically QA does not like to start over again and again.
How can we solve the problem of selectively removing streams that are obsolete or need to be recreated in a (different) way.
What are some recommendations here? Other that start over…
This will be pushed soon (on top 3 list after release coming). In mean time use new streams.
good to hear, thanks
Nthe problem with it is dealing with http caching, cache-never on all would suck we will keep cache-always on all links but head and support just a bit more tricky and non-breaking so scheduled after the breaking release coming.
Breaking release?
WHATCHU TALKIN’ 'BOUT, GREG?!
Security is the main part (acls on streams). No choice but to change client API there. Some small changes in atom (towards correctness eg header for expected version and post event). Projections approaching done (breaking changes allowed here). Breaking is a relative term from an end user point of view not that much breaking.
Greg
Ohh. Ok. As long as you don’t break my DB. 
Nah there won’t be any more stream-created events but that should be one line in your subscriber (which is now provided). We view any breaking change as … Breaking (even if jsut http).
Also worth noting that it will be a major version bump and since we're trying to follow semver, breaking changes are valid here!
Databases will definitely still work though.
Hi,
Has anything been implemented for the v3.0.0 RC that allows the recreation of deleted streams? There is talk in this post about implementing something so thought i’d check.
I’m currently running into problems during development where we are deleting then recreating some data when our site starts-up (as we don’t have anything in place to manage this yet) and getting stream is deleted exceptions. Our ids are generated by an external system so I’d prefer not to have to create another id just to solve this issue.
Thanks
Tom
(alternatively, lets say I have a Site aggregate, which has a SiteId (“com.example”) but is saved as a stream in ES using Site.Id (which is an auto-generated GUID) - what would be the best way to query for the stream by the SiteId as opposed to the Guid (which isn’t known by the rest of the system))
Yes by default in 3.0 streams are soft deleted over http and tcp
Internally it’s handled with $tb on metadata that basically says all events prior to x can be deleted.
However it has the trade off that you can’t guarantee event numbers in a stream start from 0 anymore