Tue, Nov 12
@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.
Mon, Nov 11
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?
Fri, Nov 8
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.
Thu, Nov 7
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
Tue, Nov 5
Sun, Nov 3
First patch reworked and ready for peer review again
Fri, Nov 1
The behavior described in AC should not 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.
Thu, Oct 31
Wed, Oct 30
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.
Tue, Oct 29
Thu, Oct 24
Needs discussion and decision with product after WikiCon is over.
Wed, Oct 23
@Lydia_Pintscher @Hanna_Petruschat_WMDE this can be tested on beta now
@Ladsgroup looks great! I am completely new to how dispatching works, and the added section let me understand it fully at a glance.. esp. the example is really well done!
The current version of the message have too many dynamic (moving) parts. The languages list is of unknown length to the message in json files, and the amount of grouped changed (Changed in ... ) can be of any length between 1 and 6 (for all possible combinations of aliases, label and description).
Tue, Oct 22
Needs a look into what changed in core test base classes and re-evaluate
On hold until we progress with T226975: [Story] Restructuring Wikibase extension tests