Support

Pre-sales

#22435 Suggestion for [ID] macro

Posted in ‘Pre-sales and Account Questions’
This is a public ticket

Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.

colinfrombotley
 Hi
It would help tie the backup archive and the corresponding log file if the Backup archive name
Backup archive name also supported an [ID] macro. The log file includes the id. trying to match dates & times is error prone if you are doing several backups.

Colin

nicholas
Akeeba Staff
Manager
Hello Colin,

Unfortunately this creates a chicken and egg issue. In order to get an ID you have to create a backup record in the database. Doing so requires knowing the filename with all variables (macros) expanded. However, an ID macro would require the database record to already exist.

By the way this is exactly the reason that, when you start a new backup, you get two log files generated. For example: akeeba.backend.log and akeeba.id123.log. The former is the log file which covers the backup engine actions before the backup record is created. The latter is created as soon as we have a backup record (therefore know the backup ID) and is used throughout the backup.

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!

colinfrombotley
Hi
Thanks for response, and I understand the dilema. An alternative approach would be to allow the user to give a reference value that is appended to both files, or rather all three files. At the end of the process the field could be auto incremented. Content could be restricted to numeric codes as these are recognised in all languages.

Colin

nicholas
Akeeba Staff
Manager
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!

Support Information

Working hours: Typically we work Monday to Friday, 9am to 7pm Cyprus timezone (EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets, but we cannot respond to them, outside of our working hours.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!

Summer vacations: Our support will be closed for replies and new tickets from August 6th to August 21st, 2022 due to summer vacations.