mirror of
https://github.com/moodle/moodle.git
synced 2025-01-18 22:08:20 +01:00
0a606a2be2
1. Autosave works in some ways just like a normal save. We ultimately call $behaviour->process_save() to do the work, and create a new step to hold the data. 2. However, we come in through a completely different route through the API, starting with separate auto-save methods. This keeps the auto-save changes mostly separate, and so reduced the chance of breaking existing working code. 3. When the time comes to store the auto-save step in the database, we save it using a negative sequence number. This is a clever trick that not only distinguises these steps, but also avoids unique key errors when an auto-save and a real action happen simultaneously. (There are unit tests for these tricky edge cases.) 4. When we load the data back from the database, most of the time the auto-save steps are loaded back as if they were a real save, and so the auto-saved data is used when the question is then rendered. 5. However, before we process another action, we remove the auto-saved step, so it does not appear in the final history.