Why is this being discussed? It's a pretty blatant violation of the UUID and Primary Key concepts.
I guess the long story revolves around our soft-delete practices, in which deleted entities remain in the database as "deleted=1".
So, since we're trying to re-user the UUID, and it's the PK in the images DB, this fails.
However, if you were to clean up the DB, say 'delete from images where deleted=1', you could then re-use the UUID.
I still think it's bad practice, IMO, to re-use the UUID, as images are meant to be immutable, any updates to the image should get a new UUID, and any new image should as well.
Why is this being discussed? It's a pretty blatant violation of the UUID and Primary Key concepts.
I guess the long story revolves around our soft-delete practices, in which deleted entities remain in the database as "deleted=1".
So, since we're trying to re-user the UUID, and it's the PK in the images DB, this fails.
However, if you were to clean up the DB, say 'delete from images where deleted=1', you could then re-use the UUID.
I still think it's bad practice, IMO, to re-use the UUID, as images are meant to be immutable, any updates to the image should get a new UUID, and any new image should as well.
Maybe the users want an 'undelete' call?