Reduce the number of save() operations when a Zone object is saved
#198
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
* No longer update zones with every record update, e.g. when renaming zones, creating PTR zones etc. * Improve save performance by using update_fields on save()
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
fixes #197
This PR addresses the problem of excessive
save()operations forZoneobjects on multiple levels.The main remedy is to introduce a volatile
soa_serial_dirtyattribute for zones, which can be set by other methods when the serial number of a zone needs to be increased, but not saved. This makes it possible for bulk operations on records to make sure that a zone's SOA Serial number will be updated, but without hitting the database.This feature is then used throughout the
ZoneandRecordmodels to determine if and when aZoneobject needs to be updated immediately (including the generation of a new version of the SOA record), and when it is OK to defer this operation. This is a surprisingly non-trivial decision.To support this new functionality and ensure that the serial numbers are created at the right times, the test cases for the Auto SOA Serial feature was extended to cover many edge cases.