First, I am no crypto expert although I am doing the MOOC.

I have an item which has as id: uuidv4

When I create this item:

  1. I create a new uuidv4
  2. check if it already exists
  3. and if not, I store it in the db.

Now this item can be deleted. So lets say that there could be a conversation 'about' this item. And in that conversation is stored the id of the-just-deleted-item. After the item has been deleted, the conversation is not automatically deleted. If some user now creates a new item (get new uuidv4) and passes the check-if-already-exists test, it could still reference an already existent conversation. THAT'S WRONG

To battle this, I was thinking of appending a UNIX timestamp (in secs) to the uuidv4 when it is created, then hash that, then store the hash. so the same uuid later on will have a different timestamp, and thus be different!

Question(s): Which hashing algorithm to use?

Or maybe just concatenate the uuidv4 + UNIX timestamp (in secs)?


You know, technically an uuidv4 is already designed to be unique. That's what it's for. In other words, the probability of you generating the same uuidv4 is supposed to be virtually zero. So why are you checking for duplicates?

The whole point of uuid's is to make sure nobody ever gets assigned the same one even if they all do their own separate thing without going through a central authority which keeps track of where each uuid is. So if you're using an uuid, it's questionable to expect that you will ever generate the same one twice.

Which leads me to believe that you haven't correctly identified your actual need. Do you need to bind this uuid of the item to the conversation somehow? If so, you want something similar to a deterministic hash of the item name, which will make sure that if you ever delete, say, "Item57", and then eventually add "Item57" back, you will still know which conversations are associated with this item (and no other). This way every item references only the conversations concerning it, even after they are deleted.

If you just need uniqueness and don't want (or care about) dangling references then uuidv4 already provides that, you should trust it rather than cobbling together your own scheme. If you don't trust proven algorithms, how can you ever trust your own?

Briefly, what are you trying to battle against, exactly, from a high level point of view?


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.