- User Since
- Feb 1 2019, 1:19 PM (215 w, 4 d)
- IRC Nick
- LDAP User
- Alaa Sarhan
- MediaWiki User
- Alaa Sarhan (WMDE) [ Global Accounts ]
Oct 17 2020
Dec 10 2019
Dec 9 2019
I ran the rebuild script over one of the bugged items, and this correctly fixed the entries in the new store.
🎉 not-surprising yet great news :)
Dec 6 2019
Dec 5 2019
Dec 4 2019
We moved to new store to up to Q1000. We wait for a while and move to a higher limit later
Nov 30 2019
Nov 29 2019
Nov 28 2019
Nov 27 2019
Nov 26 2019
We haven't experience any failures in production.. although it might be because we didn't yet introduce any breaking changes in CSR compared to SSR yet.
Let's remove catching DBError from DatabaseItemTermStore#storeTerms and DatabasePropertyTermStore#storeTerms separately, as they don't really provide that much valuable info in the error on top of the DBError anyway
Nov 25 2019
Nov 22 2019
First patch is ready for review again
Nov 12 2019
@Lea_Lacroix_WMDE this should be solved. Anything else to look at from your side before we resolve?
Waiting on T236681: SqlEntityInfoBuilder reads and writes from the old term store regardless of the config as caching entity info stuff might solve this problem
True. Option 1 is the status quo, and since those race-conditions are quite rare to begin with, and the point made by @Lucas_Werkmeister_WMDE about this validation not being a strict integrity check (@Lydia_Pintscher please correct us if we are making wrong assumptions here) sounds reasonable, I will continue with option 1 for now.
Nov 11 2019
For the new store, we are saving terms in a deferred update. This makes uniqueness checks:
a) if done during request, they might not catch possible collisions with values that are in deferred updates at the moment but haven't been written to db yet.
b) if done as part of the deferred update, they don't have the chance to report back collisions to the user.
We have wmf.5 in production now. This one is tagged for wmf.8. is that going to be the branch for this week's train?
Nov 8 2019
No sure how catching DBError could lead to these exceptions yet. I just removed the only place where we do that (mistakenly apparently) in a sub-task, but cannot think of a way to test that it does really solve this issue.
Nov 7 2019
first patch ready for review again .. left some comments where I'd love to have a second (or more) thought
Woohoo finally this can be tested on beta
I'm doing some cleanup work on first patch now
Nov 5 2019
Nov 3 2019
First patch reworked and ready for peer review again
Nov 1 2019
The behavior described in AC should be available fully in beta. Please have a look and test for any problems that fall into not fulfilling the AC of this task. Once you approve it, we can plan for shipping it to production on next train.
Oct 31 2019
Oct 30 2019
first patch for collision detector interfance+implementations is up for review
Moving back to To Do to cover the other bit (the unchecked Database Transactions documentation for other possible optimizations).
Per @Ladsgroup manual testing, there doesn't seem, number of writes per edit seem to be (near-)optimal .. marking that bit with a check.
After talking to @Lydia_Pintscher , we decided to go with a simpler version of the shortend version as suggested in the last comment. Task and parent Task descriptions will updated accordingly.
Another possible improvement could be to reorder the functions alphabetically, not sure if that's a commonly desired thing so I'll leave if for someone else to pick that up :)
Looks great! Resolving this as the original missing functions has been covered.