Further optimize creditnote_id generation #15235
Closed
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
|
(Standard links)
|
In case the credit notes started at an offset other than 1, avoid making a number of getcount calls equal to the offset every time you refund a contribution. Before: In a DB with 48,000 contributions having a creditnote_id but whose largest creditnote_id is 48,100, Civi makes a lookup call for every creditnote_id between CN_48001 and CN_48101 (100 queries) when refunding a contribution. After: In a DB with 48,000 contributions having a creditnote_id but whose largest creditnote_id is 48,100, Civi makes 3 db queries when refunding a contribution.
|
See also lab/Core #1308 |
|
Closing this out as code has been restructured & it won't apply now. We do also have a different plan for how to resolve the inefficiency on this now |
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.
Overview
In case the credit notes started at an offset other than 1, avoid a potentially
very slow process of creditnote generation.
This will enable users to archive ancient contributions or start their creditnotes at a non-zero offset in case of migrating to CiviCRM without importing all existing contributions.
Before
In a DB with 48,000 contributions having a creditnote_id but
whose largest creditnote_id is 48,100, Civi makes a lookup call for
every creditnote_id between CN_48001 and CN_48101 (100 queries) when
refunding a contribution.
After
After: In a DB with 48,000 contributions having a creditnote_id but
whose largest creditnote_id is 48,100, Civi makes 3 db queries when
refunding a contribution.
Technical Details
Instead of assuming that the next available creditnote_id is equal to the count plus one, then
looping upwards until you find a free one, use db queries to actually find the maximum
creditnote_id and start from there. The loop SHOULD be unnecessary now, but I haven't
deleted it in case two donations are being refunded simultaneously.
Comments
Anything else you would like the reviewer to note