We are still talking about the same thing. The new thing, let's call it FOO, would require us to:
- Store its value
- Automatically increase its value
- Guarantee the uniqueness (two backups cannot possibly have the same FOO)
- Guarantee the identity (every backup record is linked with exactly one FOO and a FOO does not exist unless it's linked to exactly one backup record)
What you have described is how the auto increment fields in MySQL work. In fact, if you try thinking of all the possibilities and the implementation of a sufficient mitigation scheme you will conclude that using a MySQL auto increment field is the right and only way. This would bring us right back to our previous dilemma.
The big problem is guaranteeing the uniqueness and identity. If two backups start around the same time from the same or a different origin we can no longer guarantee the uniqueness or identity of FOO.
I implied it before, please let me spell it out now. I have already analysed all possibilities for giving you such a variable in the name. It's just not possible without resulting in either a time paradox or accepting the not-so-distant risk of corrupt backup archives when the non-thread-safe PHP code results in the reuse of an ID when it shouldn't. Time paradoxes are currently impossible and a very real possibility of corrupt backups is out of the question.
Nicholas K. Dionysopoulos
Lead Developer and Director
🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!
