sarhan.alaa updated the task description.
TASK DETAIL
https://phabricator.wikimedia.org/T219499
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Greta_Doci_WMDE, sarhan.alaa
Cc: sarhan.alaa, Lydia_Pintscher, alaa_wmde, Lea_Lacroix_WMDE, thiemowmde
sarhan.alaa added a comment.
oh yeah sure that won't be running in production like that .. I just was
wondering if there are any extra optimization here that I could've missed re
using indexes or using the sub-queries.
re running in batches, sure it should limit deleting
sarhan.alaa added a comment.
Wow in minutes .. it took a query on wb_terms >5 minutes to get 50 results
only. Same on Query Service. How did you find those?
As for the task, this makes the costs of solution 1 we did so far even higher
than solution 2 (change SetAliases to supp
sarhan.alaa moved this task from incoming to ready to go on the Wikidata board.
sarhan.alaa added a comment.
Moved back to be briefly discussed, estimated and broken down.
TASK DETAIL
https://phabricator.wikimedia.org/T219499
WORKBOARD
https://phabricator.wikimedia.org/project/board/71
sarhan.alaa updated the task description.
TASK DETAIL
https://phabricator.wikimedia.org/T219499
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: Greta_Doci_WMDE, sarhan.alaa
Cc: sarhan.alaa, Lydia_Pintscher, alaa_wmde, Lea_Lacroix_WMDE, thiemowmde
sarhan.alaa removed a project: Wikidata-Campsite
(Wikidata-Campsite-Iteration-∞).
TASK DETAIL
https://phabricator.wikimedia.org/T219499
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: sarhan.alaa
Cc: sarhan.alaa, Lydia_Pintscher, alaa_wmde
sarhan.alaa removed Greta_Doci_WMDE as the assignee of this task.
TASK DETAIL
https://phabricator.wikimedia.org/T219499
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: sarhan.alaa
Cc: sarhan.alaa, Lydia_Pintscher, alaa_wmde, Lea_Lacroix_WMDE
sarhan.alaa closed this task as "Resolved".
sarhan.alaa added a comment.
Thanks @waldyrious very much for your contribution on the spot!
I'm marking this one resoled for now. When there are more improvements to the
documentation we'll follow up on them on github (and possibly
sarhan.alaa added a comment.
yeah we need some column for such cases.
We can call the column Ice Box ? that's a name I'm used to for stuff we
wanted to freeze for later for whatever reason.. and then the ones that are to
be ignored for real (so not freezing anymore) we would resolve
sarhan.alaa added a comment.
@WMDE-leszek that's great! I remember seeing it differently locally when I
tested adding the id back a while back, or maybe I just assed it will land on
the `a` tag from the code (that seems to do some magic there). Either way, I
should've waited and checked
sarhan.alaa added a comment.
@Ladsgroup yeah probably.. There might still some that might break because
the id now is on the `a` tag and not a wrapper element like it used to be.
If there's a way to put the id on a wrapper span (might not exist yet) it
might avoid those cases too
sarhan.alaa moved this task from Test (Verification) to To Do on the
Wikidata-Campsite (Wikidata-Campsite-Iteration-∞) board.
sarhan.alaa added a comment.
In T232595#5635743 <https://phabricator.wikimedia.org/T232595#5635743>,
@Addshore wrote:
> I guess this is still jus
sarhan.alaa claimed this task.
TASK DETAIL
https://phabricator.wikimedia.org/T232040
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: sarhan.alaa
Cc: Lydia_Pintscher, hoo, Addshore, Ladsgroup, Lucas_Werkmeister_WMDE,
Aklapper, alaa_wmde, Hook696
sarhan.alaa added a comment.
Last patch turning on validation of uniqueness in new store is ready for
review now
https://gerrit.wikimedia.org/r/c/mediawiki/extensions/Wikibase/+/553524
It has 3 little fixes below it too
TASK DETAIL
https://phabricator.wikimedia.org/T232040
EMAIL
sarhan.alaa updated the task description.
TASK DETAIL
https://phabricator.wikimedia.org/T232040
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: sarhan.alaa
Cc: Lydia_Pintscher, hoo, Addshore, Ladsgroup, Lucas_Werkmeister_WMDE,
Aklapper, alaa_wmde
sarhan.alaa added a comment.
Not sure @Ladsgroup your comments in the review do make sense.. can you
please double check them and read through the code again? I may of course have
misunderstood them, maybe little more elaboration will help
TASK DETAIL
https://phabricator.wikimedia.org
sarhan.alaa added a comment.
@addshore @ladsgroup
We are still on the plan to swit
TASK DETAIL
https://phabricator.wikimedia.org/T232040
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: sarhan.alaa
Cc: Lydia_Pintscher, hoo, Addshore, Ladsgroup
sarhan.alaa added a comment.
If reviewing the patch in the current state is too much effort or difficult
(it can be very much the case), also let me know I can try to split it up
further into couple of smaller patches
TASK DETAIL
https://phabricator.wikimedia.org/T232040
EMAIL
sarhan.alaa moved this task from Peer Review to Doing on the Wikidata-Campsite
(Wikidata-Campsite-Iteration-∞) board.
sarhan.alaa added a comment.
In T232040#5774510 <https://phabricator.wikimedia.org/T232040#5774510>,
@Addshore wrote:
> While reviewing
https://gerrit.wikime
sarhan.alaa added a comment.
Same goes for items. API calls fail manually as expected, but I can create
conflicting items through special pages. I also confirm that
`SingleEntitySourceServices::getTermSearchInteractorFactory` and
`SingleEntitySourceServices::getPrefetchingTermLookup` need
sarhan.alaa added a comment.
I added two test cases to the integration test editentity fingerprint
uniqueness. Those pass in for API calls, which I could also confirm sending API
requests manually.
But, I can also reproduce it through special pages: I can create conflicting
properties
sarhan.alaa updated the task description.
TASK DETAIL
https://phabricator.wikimedia.org/T232040
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: sarhan.alaa
Cc: Lydia_Pintscher, hoo, Addshore, Ladsgroup, Lucas_Werkmeister_WMDE,
Aklapper, alaa_wmde
sarhan.alaa added a comment.
Oh, apparently `SpecialNewEntity` creates entities without even creating
change ops. That would explain it, as then it will by-pass the whole validation
of fignreprint uniqueness that is only executed inside
`ChangeOpFingerprintResult::validate()`. Guess
sarhan.alaa updated the task description.
TASK DETAIL
https://phabricator.wikimedia.org/T232040
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: sarhan.alaa
Cc: Lydia_Pintscher, hoo, Addshore, Ladsgroup, Lucas_Werkmeister_WMDE,
Aklapper, alaa_wmde
sarhan.alaa claimed this task.
sarhan.alaa added a subscriber: sarhan.
TASK DETAIL
https://phabricator.wikimedia.org/T242204
EMAIL PREFERENCES
https://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: sarhan.alaa
Cc: sarhan, alaa_wmde, Aklapper, Lucas_Werkmeister_WMDE
sarhan.alaa moved this task from Doing to Peer Review on the Wikidata-Campsite
(Wikidata-Campsite-Iteration-∞) board.
sarhan.alaa added a comment.
I drafted a patch for this, but won't have enough time to clean it up .. it
works fine now, but the code is not the prettiest. Specifically
sarhan.alaa created this task.
sarhan.alaa added projects: Wikidata, Patch-For-Review, Wikidata-Campsite
(Wikidata-Campsite-Iteration-∞), MW-1.35-notes (1.35.0-wmf.10; 2019-12-10),
User-Addshore.
Restricted Application removed a project: Patch-For-Review.
TASK DESCRIPTION
`SpecialNewProperty
27 matches
Mail list logo