Open Stack

On Aug 20, 2013, at 1:05 PM, Jay Pipes <jaypipes at gmail.com> wrote:

> I see the following use case:
> 
> 1) Create something with a unique name within your tenant
> 2) Delete that
> 3) Create something with the same unique name immediately after
> 
> As a pointless and silly use case that we should not cater to.
> 
> It's made the database schema needlessly complex IMO and added columns to a unique constraint that make a DBA's job more complex in order to fulfill a use case that really isn't particularly compelling.
> 
> I was having a convo on IRC with Boris and stated the use case in different terms:
> 
> If you delete your Gmail email address, do you expect to immediately be able to create a new Gmail email with the previous address?
> 
> If you answer yes, then this unique constraint on the deleted column makes sense to you. If you answer no, then the whole thing seems like we've spent a lot of effort on something that isn't particularly useful except in random test cases that try to create and delete the same thing in rapid succession. And IMO, those kinds of test cases should be deleted -- hard-deleted.
> 

I would answer 'no' to the gmail question.  I would answer 'yes' depending on what other things we may talk about.  If we put (or maybe we have this -- I didn't check) unique constraints on the metadata table for metadata key… It would be rather silly to not allow someone to reset some metadata with the same key immediately.  One could argue that we just un-delete the former row and update it, however… but I think that breaks archiving (something*I'm* not a fan of ;)

- Chris