[Wikidata-bugs] [Maniphest] [Changed Project Column] T117200: [WD] Implement internal use KPI (infoboxes)

[Addshore]

Addshore moved this task to Done on the WMDE-Analytics-Engineering workboard.

TASK DETAIL
  https://phabricator.wikimedia.org/T117200

WORKBOARD
  https://phabricator.wikimedia.org/project/board/1585/

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Addshore
Cc: StudiesWorld, Addshore, Lydia_Pintscher, Abraham, Aklapper, Wikidata-bugs, 
aude, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T117533: DCAT-AP: Issued and modified should be typed

[Lokal_Profil]

Lokal_Profil added a comment.

But it isn't there in 1.00 
https://joinup.ec.europa.eu/system/files/project/dcat-ap_final_v1.00_0.html#Data%20Catalogue%20-%20release%20date

There is however not a nice table (like in 0.06 and 1.01) so it might have been 
intended but never made it in.


TASK DETAIL
  https://phabricator.wikimedia.org/T117533

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Lokal_Profil
Cc: gerritbot, StudiesWorld, Aklapper, EmidioStani, Lokal_Profil, 
Wikidata-bugs, aude, Svick, Mbch331, jeremyb



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T46874: [Epic] Full support for wikibase edits in enhanced changes format ("Group changes by page in recent changes and watchlist" [usenewrc])

[matej_suchanek]

matej_suchanek added a blocking task: T64798: [Task] Consolidate watchlist and 
recent changes hook query code in Wikibase Client.

TASK DETAIL
  https://phabricator.wikimedia.org/T46874

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: matej_suchanek
Cc: vlsergey, Simon_Villeneuve, Aklapper, MGChecker, CennoxX, mxn, 
Ricordisamoa, Perhelion, Elitre, MisterSynergy, Conny, Reaper35, liangent, 
Jdforrester-WMF, Abraham, matmarex, Nemo_bis, Schnark, Tobi_WMDE_SW, He7d3r, 
aude, Liuxinyu970226, Tgr, Lydia_Pintscher, Ltrlg, Raymond, Wikidata-bugs, 
Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T64798: [Task] Consolidate watchlist and recent changes hook query code in Wikibase Client

[matej_suchanek]

matej_suchanek added a blocked task: T46874: [Epic] Full support for wikibase 
edits in enhanced changes format ("Group changes by page in recent changes and 
watchlist" [usenewrc]).

TASK DETAIL
  https://phabricator.wikimedia.org/T64798

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: aude, matej_suchanek
Cc: Sjoerddebruin, gerritbot, daniel, Aklapper, Wikidata-bugs, aude, 
Lydia_Pintscher, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Project Column] T117421: [Story] Put identifiers into separate section in the UI

[Jonas]

Jonas moved this task to Backlog on the Wikidata-Sprint-2015-11-17 workboard.

TASK DETAIL
  https://phabricator.wikimedia.org/T117421

WORKBOARD
  https://phabricator.wikimedia.org/project/board/1620/

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Jonas
Cc: Lydia_Pintscher, Aklapper, Sjoerddebruin, Liuxinyu970226, Ltrlg, 
Daniel_Mietchen, Ricordisamoa, Legoktm, Pigsonthewing, Filceolaire, PKM, Laddo, 
Sannita, Addshore, Multichill, Bene, Tobi_WMDE_SW, Snaterlicious, thiemowmde, 
adrianheine, Micru, jayvdb, MGChecker, DSGalaktos, Agabi10, Zolo, 
Wikidata-bugs, aude, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Project Column] T117421: [Story] Put identifiers into separate section in the UI

[Jonas]

Jonas moved this task to Doing on the Wikidata-Sprint-2015-11-17 workboard.

TASK DETAIL
  https://phabricator.wikimedia.org/T117421

WORKBOARD
  https://phabricator.wikimedia.org/project/board/1620/

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Jonas
Cc: Lydia_Pintscher, Aklapper, Sjoerddebruin, Liuxinyu970226, Ltrlg, 
Daniel_Mietchen, Ricordisamoa, Legoktm, Pigsonthewing, Filceolaire, PKM, Laddo, 
Sannita, Addshore, Multichill, Bene, Tobi_WMDE_SW, Snaterlicious, thiemowmde, 
adrianheine, Micru, jayvdb, MGChecker, DSGalaktos, Agabi10, Zolo, 
Wikidata-bugs, aude, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Created] T118949: Introduce StatementSectionsView

[Jonas]

Jonas created this task.
Jonas assigned this task to thiemowmde.
Jonas added subscribers: Jonas, adrianheine, thiemowmde.
Jonas added projects: Wikidata-Sprint-2015-11-17, 
MediaWiki-extensions-WikibaseView, Wikidata-Sprint-2015-11-03, Wikidata, 
MediaWiki-extensions-WikibaseRepository, Wikibase-Quality-Constraints.
Herald added a subscriber: Aklapper.

TASK DESCRIPTION
# Implement trivial Wikibase\View\StatementSectionsView sitting between 
PropertyView or ItemView and StatementGroupListView
# Move section heading info from Wikibase\View\StatementGroupListView to 
Wikibase\View\StatementSectionsView 
# Add wikibase-statementgroup-identifiers message so that it gets 
translated before deploying

TASK DETAIL
  https://phabricator.wikimedia.org/T118949

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: thiemowmde, Jonas
Cc: thiemowmde, adrianheine, Jonas, Aklapper, Wikidata-bugs, aude, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T113347: [Task] Pre-fetch label used for summary formatting

[matej_suchanek]

matej_suchanek added a blocked task: T118935: [Bug] Entity ids not formatted in 
Wikibase watchlist edits in client.

TASK DETAIL
  https://phabricator.wikimedia.org/T113347

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: matej_suchanek
Cc: daniel, Lydia_Pintscher, Aklapper, aude, Ricordisamoa, MGChecker, 
Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Created] T118971: Add a ChangeLookup interface and convert existing ChangeLookup into SqlChangeLookup

[aude]

aude created this task.
aude added a subscriber: aude.
aude added projects: Wikidata, MediaWiki-extensions-WikibaseRepository.
Herald added a subscriber: Aklapper.

TASK DESCRIPTION
  Right now ChangeLookup implements ChunkAccess which is nice, but I think we 
need an interface that specifically returns Change objects.  The interface can 
extend ChunkAccess.
  
  The current ChangeLookup can be renamed to SqlChangeLookup.
  
  I think doing this would make it easier to test things that use ChangeLookup.

TASK DETAIL
  https://phabricator.wikimedia.org/T118971

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: aude
Cc: aude, Aklapper, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T118960: unescape escaped | from example queries

[JanZerebecki]

JanZerebecki added a subscriber: Jonas.
JanZerebecki set Security to None.

TASK DETAIL
  https://phabricator.wikimedia.org/T118960

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: JanZerebecki
Cc: Jonas, Aklapper, JanZerebecki, StudiesWorld, jkroll, Smalyshev, 
Wikidata-bugs, Jdouglas, aude, Deskana, Manybubbles, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T118162: Wikibase dispatchChanges.php runs slow, creates an absurd amount of database connections

[gerritbot]

gerritbot added a comment.

Change 253934 had a related patch set uploaded (by Ori.livneh):
Make getLaggedSlaveMode() use reuseConnection() as needed

https://gerrit.wikimedia.org/r/253934


TASK DETAIL
  https://phabricator.wikimedia.org/T118162

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: gerritbot
Cc: Tobi_WMDE_SW, ori, mobrovac, thiemowmde, aaron, jcrespo, gerritbot, daniel, 
aude, hoo, Lydia_Pintscher, Addshore, Aklapper, Joe, Wikidata-bugs, Mbch331, 
Krenair



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T118162: Wikibase dispatchChanges.php runs slow, creates an absurd amount of database connections

[gerritbot]

gerritbot added a comment.

Change 253934 merged by Ori.livneh:
Make getLaggedSlaveMode() use reuseConnection() as needed

https://gerrit.wikimedia.org/r/253934


TASK DETAIL
  https://phabricator.wikimedia.org/T118162

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: gerritbot
Cc: Tobi_WMDE_SW, ori, mobrovac, thiemowmde, aaron, jcrespo, gerritbot, daniel, 
aude, hoo, Lydia_Pintscher, Addshore, Aklapper, Joe, Wikidata-bugs, Mbch331, 
Krenair



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T118162: Wikibase dispatchChanges.php runs slow, creates an absurd amount of database connections

[mobrovac]

mobrovac added a comment.

As @ori mentioned, the https://phabricator.wikimedia.org/tag/services/ team is 
working with https://phabricator.wikimedia.org/tag/analytics/ on the 
https://phabricator.wikimedia.org/tag/eventbus/ project, whose aim is basically 
to replace jobrunners and enable efficient event propagation and delivery 
inside the production cluster (but also targeted at third-party users). In that 
context, our team plans to build change-propagation system (cf. 
https://phabricator.wikimedia.org/T102476, 
https://phabricator.wikimedia.org/T117933 and related tasks for more context) 
on top of it. And from the looks of it, that's exactly what you are trying to 
achieve with this script, isn't it?


TASK DETAIL
  https://phabricator.wikimedia.org/T118162

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: mobrovac
Cc: Tobi_WMDE_SW, ori, mobrovac, thiemowmde, aaron, jcrespo, gerritbot, daniel, 
aude, hoo, Lydia_Pintscher, Addshore, Aklapper, Joe, Wikidata-bugs, Mbch331, 
Krenair



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T118162: Wikibase dispatchChanges.php runs slow, creates an absurd amount of database connections

[daniel]

daniel added a comment.

@mobrovac Yes, and I'll be very happy to replace the entire change dispatching 
clutch with an actual event bus. I suspect it'll be a few months until we can 
do that, though. I'm in touch with Gabriel about this, though I haven't looked 
into the details. I did explain to him how our tracking/subscription system 
works, though, and I assume he's targeting this as a major use case for the 
event bus.

I'm not sure I can contribute much to the EventBus discussion right now, which 
seems to be mostly about implementation details.


TASK DETAIL
  https://phabricator.wikimedia.org/T118162

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: daniel
Cc: Tobi_WMDE_SW, ori, mobrovac, thiemowmde, aaron, jcrespo, gerritbot, daniel, 
aude, hoo, Lydia_Pintscher, Addshore, Aklapper, Joe, Wikidata-bugs, Mbch331, 
Krenair



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T117685: [Task] Tests for SearchHookHandler

[gerritbot]

gerritbot added a subscriber: gerritbot.
gerritbot added a comment.

Change 251022 merged by jenkins-bot:
Add phpunit test for SearchHookHandler

https://gerrit.wikimedia.org/r/251022


TASK DETAIL
  https://phabricator.wikimedia.org/T117685

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Lucie, gerritbot
Cc: gerritbot, thiemowmde, Tobi_WMDE_SW, Lucie, Ricordisamoa, Aklapper, 
Wikidata-bugs, aude, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Created] T118960: unescape escaped | from example queries

[JanZerebecki]

JanZerebecki created this task.
JanZerebecki added a subscriber: JanZerebecki.
JanZerebecki added projects: Wikidata, Wikidata-Query-Service.
Herald added subscribers: StudiesWorld, Aklapper.
Herald added a project: Discovery.

TASK DESCRIPTION
  Unescape escaped | from example queries, otherwise either the query or the 
wikitext is broken.
  
  Example:
  
https://www.mediawiki.org/w/index.php?title=Wikibase/Indexing/SPARQL_Query_Examples=next=1941342

TASK DETAIL
  https://phabricator.wikimedia.org/T118960

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: JanZerebecki
Cc: Aklapper, JanZerebecki, StudiesWorld, jkroll, Smalyshev, Wikidata-bugs, 
Jdouglas, aude, Deskana, Manybubbles, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T118162: Wikibase dispatchChanges.php runs slow, creates an absurd amount of database connections

[daniel]

daniel added a comment.

In https://phabricator.wikimedia.org/T118162#1813400, @jcrespo wrote:

> Connection re-use does not work if you open 900 connections at the same time 
> every 3 minutes. I have been saying that for a long time. If a DBA has to 
> explain connection reuse vs pool of connections... :-/


There seems to be a fundamental misunderstanding here. The script is not 
designed to open 900 connections, nor should it be possible for this script to 
open 900 connections, if the code in core works as I understand it. I suspect 
that we are talking about "connection re-use" at a completely different level. 
I'm talking about re-use inside the same PHP invocation, not between requests. 
Do you know the relevant code in the LoadBalancer class? Can you tell me in 
what respect I am understanding or using it wrong? Maybe Aaron could shed some 
light on this.

> > We could just as well place the locks for all client wikis on the wikidata 
> > master db. Then there should be no reason to connect to the client database 
> > at all (assuming the job queue is not using mysql).

> 

> 

> Please don't. You are moving the problem from one server to another (and a 
> more critical server). A good start would be to close connections as soon as 
> they are not needed anymore- instead of idling them. Whatever you do, please 
> do not test it in production.


The script shouldn't idle the connection really, it's actually bounded by sql 
query speed on the repo's master DB. No queries are run against other 
databases. I do not see how we would "shift the problem" - the problem is too 
many connections. What I suggest is to use one connection for everything.

We were connecting to the client databases just to obtain a named lock on that 
database. The connection then stayed open (not so great), but (according to how 
I understand LoadBalancer), we would use the same connection for all wikis on 
the same cluster - so we may end up with 10 or so open connections per script. 
Not ideal, but not catastrophic. Unless the connection wasn't getting re-used, 
and we ended up creating a new one for every wiki. To me, that seems to be the 
problem - a problem caused by the bug in core that Aaron fixed.

We could start to forcibly close the connection after every query, even if it's 
just a second or less until we are going to fire the next one. But we'd have to 
discuss why we should do that in this case, and not in others. Explicitly 
closing connections is generally Not Done in MediaWiki - we keep the same 
connection(s) alive for the duration of the request. As far as I can see, 
DatabaseBase::close and LoadBalancer::closeConnection are never called in any 
regular maintenance script or during web requests.

If the "request" (script run) lasts 10 minutes, that can of course be 
problematic, especially if there are many such scripts, and the connection 
isn't actually used. But the connection to the repo database *is* used. And we 
don't have hundreds of script instances.

Closing the connection to slave DBs (instead of using the same connection for 
all wikis on the same master), as Aude suggests, would work around the issue of 
connection re-use not working properly. My patch also works around the problem, 
by using the connection to the repo wiki for everything (which requires a 
change to the locking logic). But with LoadBalancer working correctly, neither 
should be needed to avoid opening hundreds of connections. That's either a core 
bug (probably the one Aaron fixed), or a fundamental misunderstanding on my 
part (about how LoadBalancer is supposed to be doing).

There is a lot that can and should be improved about the dispatching process. 
But the //massive// problem we are seeing is not caused by the script working 
as designed. It's caused by the script misbehaving due to, as far as I can 
tell, a core bug. Which, I think, is fixed.


TASK DETAIL
  https://phabricator.wikimedia.org/T118162

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: daniel
Cc: Tobi_WMDE_SW, ori, mobrovac, thiemowmde, aaron, jcrespo, gerritbot, daniel, 
aude, hoo, Lydia_Pintscher, Addshore, Aklapper, Joe, Wikidata-bugs, Mbch331, 
Krenair



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Created] T118968: [Task] Investigate if removing of events improves loading times

[thiemowmde]

thiemowmde created this task.
thiemowmde added subscribers: Jonas, Bene, thiemowmde, adrianheine, 
Lydia_Pintscher.
thiemowmde added projects: Wikidata, Tracking, Performance, 
MediaWiki-extensions-WikibaseRepository.
Herald added a subscriber: Aklapper.

TASK DESCRIPTION


TASK DETAIL
  https://phabricator.wikimedia.org/T118968

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: thiemowmde
Cc: Lydia_Pintscher, adrianheine, thiemowmde, Bene, Jonas, Aklapper, 
Wikidata-bugs, aude, GWicke, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T118162: Wikibase dispatchChanges.php runs slow, creates an absurd amount of database connections

[jcrespo]

jcrespo added a comment.

You are opening one connection per wiki. That is wrong. Locking per wiki will 
serve nothing.


TASK DETAIL
  https://phabricator.wikimedia.org/T118162

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: jcrespo
Cc: Tobi_WMDE_SW, ori, mobrovac, thiemowmde, aaron, jcrespo, gerritbot, daniel, 
aude, hoo, Lydia_Pintscher, Addshore, Aklapper, Joe, Wikidata-bugs, Mbch331, 
Krenair



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T109780: [Task] Enable phase 2 for Wikinews

[matej_suchanek]

matej_suchanek added a project: user-notice.

TASK DETAIL
  https://phabricator.wikimedia.org/T109780

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: matej_suchanek
Cc: Mattho69, MZMcBride, Bugreporter, Lydia_Pintscher, Aklapper, Ricordisamoa, 
Liuxinyu970226, Candalua, Johan, Luke081515, Wikidata-bugs, aude, Mbch331, Jay8g



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T117524: [Task] Enable data access for Meta

[matej_suchanek]

matej_suchanek added a project: user-notice.

TASK DETAIL
  https://phabricator.wikimedia.org/T117524

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: matej_suchanek
Cc: matej_suchanek, JackPotte, Liuxinyu970226, StudiesWorld, Matanya, mxn, 
Aklapper, Johan, Luke081515, Wikidata-bugs, Snowolf, aude, Mbch331, Jay8g, 
Krenair



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T118162: Wikibase dispatchChanges.php runs slow, creates an absurd amount of database connections

[jcrespo]

jcrespo added a comment.

  | 206189024 | wikiadmin   | 10.64.32.13:49847  | ruwikibooks  | 
Sleep   |
  | 206189066 | wikiadmin   | 10.64.32.13:49848  | sahwiki  | 
Sleep   |
  | 206189112 | wikiadmin   | 10.64.32.13:49850  | fiwikinews   | 
Sleep   |
  | 206189130 | wikiadmin   | 10.64.32.13:49852  | jawikinews   | 
Sleep   |
  | 206189143 | wikiadmin   | 10.64.32.13:49853  | extwiki  | 
Sleep   |
  | 206189185 | wikiadmin   | 10.64.32.13:49854  | eswikiquote  | 
Sleep   |
  | 206189249 | wikiadmin   | 10.64.32.13:49855  | emlwiki  | 
Sleep   |
  | 206189352 | wikiadmin   | 10.64.32.13:49856  | elwikiquote  | 
Sleep   |
  | 206189416 | wikiadmin   | 10.64.32.13:49857  | eewiki   | 
Sleep   |
  | 206201258 | wikiadmin   | 10.64.32.13:49862  | iswikisource | 
Sleep   |
  | 206201331 | wikiadmin   | 10.64.32.13:49865  | idwikisource | 
Sleep   |
  | 206201543 | wikiadmin   | 10.64.32.13:49868  | tewiki   | 
Sleep   |
  | 206201727 | wikiadmin   | 10.64.32.13:49869  | hiwikibooks  | 
Sleep   |
  | 206201784 | wikiadmin   | 10.64.32.13:49870  | ocwikibooks  | 
Sleep   |
  | 206201872 | wikiadmin   | 10.64.32.13:49874  | ttwiki   | 
Sleep   |
  | 206201886 | wikiadmin   | 10.64.32.13:49875  | svwikiquote  | 
Sleep   |
  | 206201994 | wikiadmin   | 10.64.32.13:49877  | sdwiki   | 
Sleep   |
  | 206202023 | wikiadmin   | 10.64.32.13:49878  | oswiki   | 
Sleep   |
  | 206202074 | wikiadmin   | 10.64.32.13:49879  | orwiki   | 
Sleep   |
  | 206202103 | wikiadmin   | 10.64.32.13:49880  | tnwiki   | 
Sleep   |
  1060 rows in set (0.00 sec)

1060 connections is the low point of it, when we reach 3000 we are close to 
exhausting them.


TASK DETAIL
  https://phabricator.wikimedia.org/T118162

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: jcrespo
Cc: Tobi_WMDE_SW, ori, mobrovac, thiemowmde, aaron, jcrespo, gerritbot, daniel, 
aude, hoo, Lydia_Pintscher, Addshore, Aklapper, Joe, Wikidata-bugs, Mbch331, 
Krenair



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T118968: [Task] Investigate if removing of events improves loading times

[thiemowmde]

thiemowmde added a comment.

I added log code to `TemplatedWidget._trigger` and found that an example item 
in my local repository with 31 snaks in 31 statements calls `this._trigger` 975 
times on load. That's an awful lot, considering that most of these events do 
not have a listener.

When I disable all these events with a simple `return`, the duration of the 
final DOM load event (I assume this is the place where I can see the impact of 
these events in Firefox' performance monitor) goes down from 1200ms to 600ms.

Note that this experiment only covers `._trigger(` calls. There are also a few 
`.trigger(` calls in our code base, e.g. in snakview.variations…

- 42 addtoolbarcreate
- 42 addtoolbarinit
- 5 aliasesviewcreate
- 5 aliasesviewinit
- 7 badgeselectorcreate
- 7 badgeselectorinit
- 4 closeablecreate
- 4 closeableinit
- 4 closeableupdate
- 5 descriptionviewcreate
- 5 descriptionviewinit
- 31 editabletemplatedwidgetcreate
- 31 editabletemplatedwidgetinit
- 35 edittoolbarcreate
- 35 edittoolbarinit
- 1 entitytermsforlanguagelistviewcreate
- 1 entitytermsforlanguagelistviewinit
- 5 entitytermsforlanguageviewcreate
- 5 entitytermsforlanguageviewinit
- 1 entitytermsviewcreate
- 1 entitytermsviewinit
- 1 itemviewcreate
- 1 itemviewinit
- 5 labelviewcreate
- 5 labelviewinit
- 63 listviewcreate
- 63 listviewinit
- 85 listviewitemadded
- 7 referenceviewcreate
- 7 referenceviewinit
- 1 sitelinkgrouplistviewcreate
- 1 sitelinkgrouplistviewinit
- 3 sitelinkgroupviewcreate
- 3 sitelinkgroupviewinit
- 3 sitelinklistviewcreate
- 3 sitelinklistviewinit
- 7 sitelinkviewcreate
- 7 sitelinkviewinit
- 9 snaklistviewcreate
- 9 snaklistviewinit
- 44 snakviewcreate
- 44 snakviewinit
- 1 statementgrouplistviewcreate
- 1 statementgrouplistviewinit
- 10 statementgroupviewcreate
- 10 statementgroupviewinit
- 10 statementlistviewcreate
- 10 statementlistviewinit
- 31 statementviewcreate
- 31 statementviewinit
- 77 toolbarbuttoncreate
- 77 toolbarbuttoninit
- 35 toolbarcreate
- 35 toolbarinit


TASK DETAIL
  https://phabricator.wikimedia.org/T118968

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: thiemowmde
Cc: Lydia_Pintscher, adrianheine, thiemowmde, Bene, Jonas, Aklapper, 
Wikidata-bugs, aude, GWicke, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T110902: [Bug] Table of content too large on mobile Wikidata

[gerritbot]

gerritbot added a comment.

Change 253935 had a related patch set uploaded (by Thiemo Mättig (WMDE)):
Add class="mw-editsection" to headlines on entity pages

https://gerrit.wikimedia.org/r/253935


TASK DETAIL
  https://phabricator.wikimedia.org/T110902

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Bene, gerritbot
Cc: Jonas, Tobi_WMDE_SW, Liuxinyu970226, Bene, thiemowmde, adrianheine, 
Snaterlicious, Aklapper, Florian, MaxSem, Lydia_Pintscher, Moushira, gerritbot, 
Wikidata-bugs, aude, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Triaged] T118850: Delete daily.wikidata.api.getclaims_property_use.* Graphite metrics

[Addshore]

Addshore triaged this task as "Normal" priority.
Addshore set Security to None.

TASK DETAIL
  https://phabricator.wikimedia.org/T118850

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Addshore
Cc: Aklapper, Addshore, StudiesWorld, Wikidata-bugs, aude, Mbch331, fgiunchedi



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Triaged] T117732: Create a Graphite instance in the Analytics cluster

[Addshore]

Addshore triaged this task as "Low" priority.

TASK DETAIL
  https://phabricator.wikimedia.org/T117732

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Addshore
Cc: Joe, Lydia_Pintscher, fgiunchedi, Christopher, JanZerebecki, Nuria, 
Ottomata, Aklapper, Addshore, StudiesWorld, Wikidata-bugs, aude, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Assigned] T118950: [Task] Introduce StatementGrouper

[Jonas]

Jonas assigned this task to thiemowmde.
Jonas set Security to None.

TASK DETAIL
  https://phabricator.wikimedia.org/T118950

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: thiemowmde, Jonas
Cc: Jonas, adrianheine, thiemowmde, Aklapper, Wikidata-bugs, aude, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T108688: [Story] meaningful edit summaries on the client

[matej_suchanek]

matej_suchanek added a blocking task: T118935: [Bug] Entity ids not formatted 
in Wikibase watchlist edits in client.

TASK DETAIL
  https://phabricator.wikimedia.org/T108688

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: matej_suchanek
Cc: MGChecker, Ricordisamoa, aude, Aklapper, Lydia_Pintscher, Wikidata-bugs, 
Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T118935: [Bug] Entity ids not formatted in Wikibase watchlist edits in client

[matej_suchanek]

matej_suchanek added a blocking task: T113347: [Task] Pre-fetch label used for 
summary formatting.

TASK DETAIL
  https://phabricator.wikimedia.org/T118935

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: matej_suchanek
Cc: aude, Aklapper, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T118935: [Bug] Entity ids not formatted in Wikibase watchlist edits in client

[matej_suchanek]

matej_suchanek added a blocked task: T108688: [Story] meaningful edit summaries 
on the client.

TASK DETAIL
  https://phabricator.wikimedia.org/T118935

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: matej_suchanek
Cc: aude, Aklapper, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T118949: [Task] Introduce StatementSectionsView

[gerritbot]

gerritbot added a project: Patch-For-Review.

TASK DETAIL
  https://phabricator.wikimedia.org/T118949

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: thiemowmde, gerritbot
Cc: gerritbot, thiemowmde, adrianheine, Jonas, Aklapper, Wikidata-bugs, aude, 
Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T117524: [Task] Enable data access for Meta

[matej_suchanek]

matej_suchanek added a subscriber: matej_suchanek.
matej_suchanek added a comment.

@JackPotte That's problem of T109780: [Task] Enable phase 2 for Wikinews 
.


TASK DETAIL
  https://phabricator.wikimedia.org/T117524

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: matej_suchanek
Cc: matej_suchanek, JackPotte, Liuxinyu970226, StudiesWorld, Matanya, mxn, 
Aklapper, Luke081515, Wikidata-bugs, Snowolf, aude, Mbch331, Krenair



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T117533: DCAT-AP: Issued and modified should be typed

[EmidioStani]

EmidioStani added a comment.

I don't see on the website the version 1.00 as PDF and I do agree with you it 
is not there. I think that html table is not fully descriptive compared to the 
PDF we should ask to the authors the version 1.00


TASK DETAIL
  https://phabricator.wikimedia.org/T117533

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Lokal_Profil, EmidioStani
Cc: gerritbot, StudiesWorld, Aklapper, EmidioStani, Lokal_Profil, 
Wikidata-bugs, aude, Svick, Mbch331, jeremyb



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Project Column] T118949: Introduce StatementSectionsView

[Jonas]

Jonas moved this task to Doing on the Wikidata-Sprint-2015-11-17 workboard.

TASK DETAIL
  https://phabricator.wikimedia.org/T118949

WORKBOARD
  https://phabricator.wikimedia.org/project/board/1620/

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: thiemowmde, Jonas
Cc: thiemowmde, adrianheine, Jonas, Aklapper, Wikidata-bugs, aude, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T118949: [Task] Introduce StatementSectionsView

[gerritbot]

gerritbot added a comment.

Change 253912 had a related patch set uploaded (by Thiemo Mättig (WMDE)):
Introduce and start using StatementSectionsView

https://gerrit.wikimedia.org/r/253912


TASK DETAIL
  https://phabricator.wikimedia.org/T118949

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: thiemowmde, gerritbot
Cc: gerritbot, thiemowmde, adrianheine, Jonas, Aklapper, Wikidata-bugs, aude, 
Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Project Column] T118950: [Task] Introduce StatementGrouper

[Jonas]

Jonas moved this task to Doing on the Wikidata-Sprint-2015-11-17 workboard.

TASK DETAIL
  https://phabricator.wikimedia.org/T118950

WORKBOARD
  https://phabricator.wikimedia.org/project/board/1620/

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Jonas
Cc: Jonas, adrianheine, thiemowmde, Aklapper, Wikidata-bugs, aude, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Retitled] T118949: [Task] Introduce StatementSectionsView

[Jonas]

Jonas changed the title from "Introduce StatementSectionsView " to "[Task] 
Introduce StatementSectionsView ".
Jonas set Security to None.

TASK DETAIL
  https://phabricator.wikimedia.org/T118949

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: thiemowmde, Jonas
Cc: thiemowmde, adrianheine, Jonas, Aklapper, Wikidata-bugs, aude, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T118949: [Task] Introduce StatementSectionsView

[gerritbot]

gerritbot added a subscriber: gerritbot.
gerritbot added a comment.

Change 253911 had a related patch set uploaded (by Thiemo Mättig (WMDE)):
Add "Identifiers" section heading for wikidata.org

https://gerrit.wikimedia.org/r/253911


TASK DETAIL
  https://phabricator.wikimedia.org/T118949

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: thiemowmde, gerritbot
Cc: gerritbot, thiemowmde, adrianheine, Jonas, Aklapper, Wikidata-bugs, aude, 
Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Created] T118950: [Task] Introduce StatementGrouper

[Jonas]

Jonas created this task.
Jonas added subscribers: thiemowmde, adrianheine, Jonas.
Jonas added projects: Wikidata-Sprint-2015-11-17, 
MediaWiki-extensions-WikibaseView, Wikidata-Sprint-2015-11-03, Wikidata, 
MediaWiki-extensions-WikibaseRepository, Wikibase-Quality-Constraints.
Herald added a subscriber: Aklapper.

TASK DESCRIPTION
# Implement StatementGrouper (StatementGrouper::groupStatements( 
StatementList ) -> StatementList[]) interface and trivial implementation 
SingleGroupStatementGrouper
   
# Implement FilteringStatementGrouper( defaultGroup, StatementFilter[] )
# Use trivial StatementGrouper in StatementSectionsView (Also depends on 
StatementSectionsView)

TASK DETAIL
  https://phabricator.wikimedia.org/T118950

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Jonas
Cc: Jonas, adrianheine, thiemowmde, Aklapper, Wikidata-bugs, aude, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Created] T118951: [Task] Implement ByMainSnakPropertyDataTypeStatementFilter

[Jonas]

Jonas created this task.
Jonas added subscribers: thiemowmde, Jonas, adrianheine.
Jonas added projects: Wikidata-Sprint-2015-11-17, 
MediaWiki-extensions-WikibaseView, Wikidata-Sprint-2015-11-03, Wikidata, 
MediaWiki-extensions-WikibaseRepository, Wikibase-Quality-Constraints.
Herald added a subscriber: Aklapper.

TASK DESCRIPTION
  [PHP, datamodel services?] Implement ByMainSnakPropertyDataTypeStatementFilter

TASK DETAIL
  https://phabricator.wikimedia.org/T118951

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Jonas
Cc: Aklapper, adrianheine, Jonas, thiemowmde, Wikidata-bugs, aude, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Project Column] T118951: [Task] Implement ByMainSnakPropertyDataTypeStatementFilter

[Jonas]

Jonas moved this task to Backlog on the Wikidata-Sprint-2015-11-17 workboard.

TASK DETAIL
  https://phabricator.wikimedia.org/T118951

WORKBOARD
  https://phabricator.wikimedia.org/project/board/1620/

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Jonas
Cc: Aklapper, adrianheine, Jonas, thiemowmde, Wikidata-bugs, aude, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T64874: [Story] Statistics for Special:EntityData usage

[Addshore]

Addshore added a comment.

Daily would be good.
Grouped by format.
We can probably ignore /entity/ as they should all redirect to 
Special:EntityData.


TASK DETAIL
  https://phabricator.wikimedia.org/T64874

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Addshore
Cc: JAllemandou, Halfak, hoo, Addshore, Ricordisamoa, Aklapper, drdee, Tnegrin, 
QChris, ezachte, Lydia_Pintscher, daniel, Wikidata-bugs, aude, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T118162: Wikibase dispatchChanges.php runs slow, creates an absurd amount of database connections

[ReleaseTaggerBot]

ReleaseTaggerBot added a project: WMF-deploy-2015-11-10_(1.27.0-wmf.6).

TASK DETAIL
  https://phabricator.wikimedia.org/T118162

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: ReleaseTaggerBot
Cc: Tobi_WMDE_SW, ori, mobrovac, thiemowmde, aaron, jcrespo, gerritbot, daniel, 
aude, hoo, Lydia_Pintscher, Addshore, Aklapper, Joe, Wikidata-bugs, Mbch331, 
Krenair



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T109780: [Task] Enable phase 2 for Wikinews

[Lydia_Pintscher]

Lydia_Pintscher added a comment.

This will be done on Dec 2nd.


TASK DETAIL
  https://phabricator.wikimedia.org/T109780

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Lydia_Pintscher
Cc: Mattho69, MZMcBride, Bugreporter, Lydia_Pintscher, Aklapper, Ricordisamoa, 
Liuxinyu970226, Candalua, Johan, Luke081515, Wikidata-bugs, aude, Mbch331, Jay8g



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T117611: Create a dashboard showing how many error/timeout requests are in WDQS

[Addshore]

Addshore added a comment.

@Ironholds I think we will leave the WDQS dashboard to you! :)
We now link to the WDQS dash @ 
https://grafana.wikimedia.org/dashboard/db/wikidata


TASK DETAIL
  https://phabricator.wikimedia.org/T117611

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Addshore
Cc: Deskana, Addshore, mpopov, Ironholds, Aklapper, StudiesWorld, Smalyshev, 
jkroll, Wikidata-bugs, Jdouglas, aude, Manybubbles, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Closed] T118162: Wikibase dispatchChanges.php runs slow, creates an absurd amount of database connections

[jcrespo]

jcrespo closed this task as "Resolved".
jcrespo claimed this task.
jcrespo added a comment.

Resolving, and hopefuly future issues can be resolved in further tickets. I am 
ok with the current state.


TASK DETAIL
  https://phabricator.wikimedia.org/T118162

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: jcrespo
Cc: Tobi_WMDE_SW, ori, mobrovac, thiemowmde, aaron, jcrespo, gerritbot, daniel, 
aude, hoo, Lydia_Pintscher, Addshore, Aklapper, Joe, Wikidata-bugs, Mbch331, 
Krenair



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T118739: Requesting access to dataset-admins for Addshore

[Addshore]

Addshore added a comment.

I am fine with doing it either way :)
Someone from the analytics team may also have an opinion though!


TASK DETAIL
  https://phabricator.wikimedia.org/T118739

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Addshore
Cc: gerritbot, ArielGlenn, hoo, Deskana, Aklapper, Addshore, Wikidata-bugs, 
aude, mark, JanZerebecki, Mbch331, Krenair



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T117524: [Task] Enable data access for Meta

[Lydia_Pintscher]

Lydia_Pintscher added a subscriber: Lydia_Pintscher.
Lydia_Pintscher added a comment.

This will be done on Dec 2nd.


TASK DETAIL
  https://phabricator.wikimedia.org/T117524

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Lydia_Pintscher
Cc: Lydia_Pintscher, matej_suchanek, JackPotte, Liuxinyu970226, StudiesWorld, 
Matanya, mxn, Aklapper, Johan, Luke081515, Wikidata-bugs, Snowolf, aude, 
Mbch331, Jay8g, Krenair



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T118860: [Tracking] Represent derived data in the data model

[daniel]

daniel added a comment.

In https://phabricator.wikimedia.org/T118860#1813512, @mkroetzsch wrote:

> When things have a conceptual dependency, it is not bad design to have a code 
> dependency there as well.


I agree, but that dependency should be as narrow as possible. The code that 
creates an HTML link from a SiteLink should have a dependency on an interface 
that provides a URL for the SiteLink. It should not known about lookups, and 
definitely not about database.  More importantly, the code that tests the 
render code should know nothing about databases.

> I don't think there is any reason to have duplicate code in either solution 
> -- that's just a matter of coordinating work within the team (not saying it 
> is easy, but architecture alone will not solve this ...).


We have discussed several options and approaches in detail, over months. This 
is the result. See https://phabricator.wikimedia.org/T112550 and 
https://phabricator.wikimedia.org/T112547 for some discussion of other 
approaches.

> > Relying on global state like that for conveniance is what MediaWiki is 
> > doing all over the place, with horrible results for testability and 
> > modularity

> 

> 

> Regarding testing, I guess you already have a mock db connection object 
> anyway (otherwise, how would you test db read operations ...). I don't see a 
> reason why this solution should be any less modular or testable than what you 
> propose. There is also no need to have any duplicate code.


Because you are proposing strong coupling between rendering/serialization and 
storage layer code. We do have a mock database for testing database level code. 
It should not be needed anywhere else.


TASK DETAIL
  https://phabricator.wikimedia.org/T118860

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: daniel
Cc: mkroetzsch, adrianheine, hoo, thiemowmde, aude, Jonas, JanZerebecki, 
JeroenDeDauw, Aklapper, StudiesWorld, daniel, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Project Column] T118968: [Task] Investigate if removing of events improves loading times

[Lydia_Pintscher]

Lydia_Pintscher moved this task to consider for next sprint on the Wikidata 
workboard.

TASK DETAIL
  https://phabricator.wikimedia.org/T118968

WORKBOARD
  https://phabricator.wikimedia.org/project/board/71/

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Lydia_Pintscher
Cc: Lydia_Pintscher, adrianheine, thiemowmde, Bene, Jonas, Aklapper, 
Wikidata-bugs, aude, GWicke, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T118860: [Tracking] Represent derived data in the data model

[JanZerebecki]

JanZerebecki added a comment.

> When things have a conceptual dependency, it is not bad design to have a code 
> dependency there as well.


As far as I understand that, it argues for tight coupling (i.e. 
Sites::getSingleton() where the URL is used). Arguing for loose coupling might 
read like this:

"When things have a conceptual dependency they should share an interface and 
the dependency should be injected. The origin of dependency, and the 
implementation should have a code dependency on the interface, not on each 
other."

> Relying on global state like that for conveniance is what MediaWiki is doing 
> all over the place, with horrible results for testability and modularity.




> so there is no state (global or local) involved and you can indeed use static 
> code if you like


State was here referring to names that are in scope. Static code is global, you 
can not replace a call to Sites::getSingleton() with a call to a mock without 
changing the global named Sites. Thus using static code makes it harder to test 
units in isolation, where the dependencies are replaced with mocks.


TASK DETAIL
  https://phabricator.wikimedia.org/T118860

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: JanZerebecki
Cc: mkroetzsch, adrianheine, hoo, thiemowmde, aude, Jonas, JanZerebecki, 
JeroenDeDauw, Aklapper, StudiesWorld, daniel, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T118162: Wikibase dispatchChanges.php runs slow, creates an absurd amount of database connections

[ori]

ori added a comment.

https://phabricator.wikimedia.org/tag/wikidata/ folks (especially @daniel and 
@Lydia_Pintscher): Just a quick note to apologize for my conduct on this task. 
I think I was quick to escalate things, and I did it in a manner that probably 
only succeeded at raising the stress level of everyone involved. I'll treat it 
as a learning experience. :)


TASK DETAIL
  https://phabricator.wikimedia.org/T118162

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: jcrespo, ori
Cc: Tobi_WMDE_SW, ori, mobrovac, thiemowmde, aaron, jcrespo, gerritbot, daniel, 
aude, hoo, Lydia_Pintscher, Addshore, Aklapper, Joe, Wikidata-bugs, Mbch331, 
Krenair



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T118162: Wikibase dispatchChanges.php runs slow, creates an absurd amount of database connections

[Lydia_Pintscher]

Lydia_Pintscher added a comment.

@ori: Don't worry. We have it fixed and will do some more to make it better. I 
understand it sucks when these things break so badly.


TASK DETAIL
  https://phabricator.wikimedia.org/T118162

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: jcrespo, Lydia_Pintscher
Cc: Tobi_WMDE_SW, ori, mobrovac, thiemowmde, aaron, jcrespo, gerritbot, daniel, 
aude, hoo, Lydia_Pintscher, Addshore, Aklapper, Joe, Wikidata-bugs, Mbch331, 
Krenair



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T118860: [Tracking] Represent derived data in the data model

[mkroetzsch]

mkroetzsch added a comment.

I don't want to detail every bit here, but it should be clear that one can 
easily eliminate the dependency to $db in the formatter code. The Sites object 
I mentioned is an example. It is *not* static in our implementation. You can 
make it an interface. You can inject Sites (or a mocked version of it) for 
testing -- this is what we do. The only dependency you will retain is that the 
formatting code, or some code that calls the formatting code, must know where 
to get the URL from.

All of this will work in any "sane" architecture -- I don't see where you need 
a role manager for this. In particular, you can always pull out dependencies by 
injecting interface-based objects instead, and this has nothing to do with how 
you represent the "derived data" in memory using objects. The role-based 
approach discussed here simply seems to be a generalised version of this 
pattern, with a one-solution-fits-all interface ("Role") instead of 
task-specific interfaces ("Sites" etc.). The reason why I am not convinced by 
this here is that the tasks at hand are quite diverse and refer to different 
objects. So for any particular object (such as SiteLink) you might not have 
many possible roles available, probably just one, and in such a situation the 
complexity of the general solution might be avoidable.

Maybe it's clearer if I say it in terms of the simpler "hash map of additional 
data" approach that @adrianheine mentioned: it seems to me you are adding such 
hashmaps to all objects (using a somewhat complicated way to encode the 
hashmap), just to have one or two entries per object in the end. In such a 
case, rather than using a hashmap, you would better use a member variable that 
can be null if the additional data is not there.


TASK DETAIL
  https://phabricator.wikimedia.org/T118860

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: mkroetzsch
Cc: mkroetzsch, adrianheine, hoo, thiemowmde, aude, Jonas, JanZerebecki, 
JeroenDeDauw, Aklapper, StudiesWorld, daniel, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T118860: [Tracking] Represent derived data in the data model

[hoo]

hoo added a subscriber: hoo.
hoo added a comment.

After reading about the role object pattern for a bit, I agree that this is a 
good approach. The idea above makes sense to me, I'm just a little worried 
about performance (we need to make sure that we don't create to many objects in 
the process, as that's painfully slow). We probably want to make sure we reuse 
objects for the same purpose as much as possible here.


TASK DETAIL
  https://phabricator.wikimedia.org/T118860

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: hoo
Cc: hoo, thiemowmde, aude, Jonas, JanZerebecki, JeroenDeDauw, Aklapper, 
StudiesWorld, daniel, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T117421: [Story] Put identifiers into separate section in the UI

[adrianheine]

adrianheine added a comment.

I think we could re-use and generalize that ›statement group‹ term if we would 
want to. It's only used in Wikibase view, Wikibase datamodel JavaScript and one 
location in Wikibase client. I have a hard time coming up with a better name 
for the general concept instead. We could use ›partition‹ instead, making the 
service class interface something like `StatementListPartitioner`, but that 
feels really awkward compared to `StatementGrouper`, considering that the 
latter is just a special case of the former.

As for the infrastructure in JS, it seems necessary for the approach I would 
take. The problem we need to solve in JS is that our views basically need two 
inputs: The data model object they are representing (`this.options.value`) and 
the DOM element they are working on (`this.element[0]`). These must match, 
obviously. Currently, we traverse the entity and the DOM and expect both to 
match. That's not completely wrong, but it's not so great either. Introducing 
multiple statement sections would be reflected in the DOM, but not in data 
model entity. So we need a way to order and group the data model data so that 
it matches the DOM. My proposal would be to do that in 
`wikibase.view.StatementSectionsView` using a `StatementGrouper`. So, 
`StatementSectionsView` would get the `wikibase.datamodel.StatementGroupSet` 
(basically a hash map from `propertyId` to `StatementList`) and build a list of 
`StatementGroupSet`s using the `StatementGrouper`.

Another approach would be to ditch `wbEntity`, just follow the structure of the 
DOM and pass the editable data model objects in a flat structure, i. e. 
`wbEntityStatements = { guid: wb.datamodel.Statement }`. The `statementview` 
would then either fetch its `Statement` object from a store it got passed in 
using the guid that's represented somewhere in the DOM or some factory would 
inspect the DOM, grab the guid, fetch the `Statement` object and give it to the 
`statementview`. That's a quite some work to implement, would probably be a lot 
nicer, but would probably also mean that we won't be able to easily construct 
an `entityview` without DOM. Something we don't do anyway, currently. I'd 
prefer to not tie identifier sections to that change, if we actually want to do 
it, though.


TASK DETAIL
  https://phabricator.wikimedia.org/T117421

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: adrianheine
Cc: Lydia_Pintscher, Aklapper, Sjoerddebruin, Liuxinyu970226, Ltrlg, 
Daniel_Mietchen, Ricordisamoa, Legoktm, Pigsonthewing, Filceolaire, PKM, Laddo, 
Sannita, Addshore, Multichill, Bene, Tobi_WMDE_SW, Snaterlicious, thiemowmde, 
adrianheine, Micru, jayvdb, MGChecker, DSGalaktos, Agabi10, Zolo, 
Wikidata-bugs, aude, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T118162: Wikibase dispatchChanges.php runs slow, creates an absurd amount of database connections

[jcrespo]

jcrespo added a comment.

I am thinking of killing and banning these connections right now from s3 
because it is breaking our database servers. It is still creating 1000-2000 
idle connections to db1035.


TASK DETAIL
  https://phabricator.wikimedia.org/T118162

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: jcrespo
Cc: thiemowmde, aaron, jcrespo, gerritbot, daniel, aude, hoo, Lydia_Pintscher, 
Addshore, Aklapper, Joe, Wikidata-bugs, Mbch331, Krenair



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T115117: [RfC] PageTerms API module should work on entity pages and connected pages on a wiki with repo and client functionality enabled.

[daniel]

daniel added a project: Wikidata-Sprint-2015-11-17.
Herald added a subscriber: StudiesWorld.

TASK DETAIL
  https://phabricator.wikimedia.org/T115117

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: daniel
Cc: StudiesWorld, Tobi_WMDE_SW, JanZerebecki, Aklapper, daniel, Wikidata-bugs, 
aude, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T90870: selfcontained projects around Wikidata (tracking)

[Qgil]

Qgil removed a subscriber: Qgil.

TASK DETAIL
  https://phabricator.wikimedia.org/T90870

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Qgil
Cc: Ricordisamoa, mkroetzsch, Aklapper, Lydia_Pintscher, Wikidata-bugs, aude, 
Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T118000: Cannot use Chinese IME in label table

[Liuxinyu970226]

Liuxinyu970226 set Security to None.

TASK DETAIL
  https://phabricator.wikimedia.org/T118000

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Liuxinyu970226
Cc: Liuxinyu970226, thiemowmde, Lydia_Pintscher, Aklapper, deryckchan, 
StudiesWorld, Wikidata-bugs, aude, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T118000: Cannot use Chinese IME in label table

[Liuxinyu970226]

Liuxinyu970226 added a subscriber: Liuxinyu970226.

TASK DETAIL
  https://phabricator.wikimedia.org/T118000

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Liuxinyu970226
Cc: Liuxinyu970226, thiemowmde, Lydia_Pintscher, Aklapper, deryckchan, 
StudiesWorld, Wikidata-bugs, aude, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Project Column] T117458: Implement SiteLookup based on JSON files

[daniel]

daniel moved this task to consider for next sprint on the Wikidata workboard.
Herald added a subscriber: StudiesWorld.

TASK DETAIL
  https://phabricator.wikimedia.org/T117458

WORKBOARD
  https://phabricator.wikimedia.org/project/board/71/

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: daniel
Cc: StudiesWorld, aude, Aklapper, daniel, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T118860: [Tracking] Represent derived data in the data model

[daniel]

daniel added a comment.

In https://phabricator.wikimedia.org/T118860#1813397, @mkroetzsch wrote:

> Structurally, this would work, but it seems like a very general solution with 
> a lot of overhead. Not sure that this pattern works well on PHP, where the 
> cost of creating additional objects is huge. I also wonder whether it really 
> is good to manage all those (very different!) types of "derived" information 
> in a uniform way.


The need for this solution is driven by the fact that using separate 
implementation strategies for the different kinds of derived data was worked 
rather badly for us in the past to iterations of the serialization code. We 
ended up with a lot of inconsistencies and duplicate code.

I do share the concern about performance. I think it is managable, but we 
should be careful about this. I think deferred deserialization is going to be 
key to that.

> To pick just one example, consider the (article) URL of a SiteLink. To create 
> it, one needs to have access to the content of the sites table. In WDTK, we 
> encapsulate the sites table in an object (called Sites). To find out the URL 
> of a SiteLink, one has to call a method of the Sites object (called 
> getArticleUrl() or something), which takes a SiteLink as an input. This 
> design is simple and efficient, uses no additional memory for storing new 
> objects or values, and clearly locates the responsibility for computing this 
> information (the Sites table).


But it requires the serialization and formatting code to depend on the lookup 
services, and have these lookup services injected. We have found that this is a 
bad thing, both in theory (representing all data in a dumb model before 
generating output was suggested by two external reviews) and in practice (where 
the cross-dependencies have kept us from splitting serialization code into a 
separate component for a long time).

> In a single-site setting (like you have in PHP), there is only one sites 
> table, and you can access it statically, so the caller does not even need to 
> have a reference to a Sites object as in WDTK. I therefore don't see any 
> benefit in creating a role object for this simple task. It's just more 
> indirection, without any convenience for the software developer or any gain 
> in performance.


Relying on global state like that for conveniance is what MediaWiki is doing 
all over the place, with horrible results for testability and modularity. 
Getting away from that tangle is one of my main priorities as a core architect.

> There is only going to be a small number of different kinds of "derived data" 
> ever, and there is hardly any place where such data is used in a way that 
> does not need to understand its meaning (mainly for serialization).


You always need to understand the meaning in order to use it. That's why roles 
are defined by interfaces. We are not passing around random blobs with random 
names.

> I suppose that this proposal has nothing to do with JSON or RDF, but just to 
> be sure we are on the same page.


Yes, this has nothing to do with JSON and RDF. Depending on the type of 
information, it would be represented in structurally different ways in the 
exported data structure. We have separate tickets for that.

> The term "data model" is a bit over-used in our context -- maybe it would 
> make sense to indicate in this bug report that it is specific to the object 
> model used in the PHP implementation, and has no implications for other 
> implementations or export formats.


You are right, this refers specifically to the PHP wikibase/data-model 
component.


TASK DETAIL
  https://phabricator.wikimedia.org/T118860

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: daniel
Cc: mkroetzsch, adrianheine, hoo, thiemowmde, aude, Jonas, JanZerebecki, 
JeroenDeDauw, Aklapper, StudiesWorld, daniel, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T118162: Wikibase dispatchChanges.php runs slow, creates an absurd amount of database connections

[ori]

ori added subscribers: mobrovac, ori.
ori added a comment.

@daniel, could you please make sure to sync up with the Services team to see 
how https://phabricator.wikimedia.org/T114443 could lay the groundwork for 
solving this problem better? @mobrovac, could you please act as liaison / 
point-person?


TASK DETAIL
  https://phabricator.wikimedia.org/T118162

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: ori
Cc: ori, mobrovac, thiemowmde, aaron, jcrespo, gerritbot, daniel, aude, hoo, 
Lydia_Pintscher, Addshore, Aklapper, Joe, Wikidata-bugs, Mbch331, Krenair



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T118860: [Tracking] Represent derived data in the data model

[daniel]

daniel added a comment.

In https://phabricator.wikimedia.org/T118860#1813279, @adrianheine wrote:

> That looks to me like a fancier and less understandable way of just having an 
> `additionalData` hash on each data model object. Did I miss something?


That's pretty much it, yes.

> The Role Object Pattern doesn't help saying anything about the name of roles 
> or the type of role objects as far as I see it. Just as a hash, it stores 
> arbitrary things under arbitrary keys.


The names would be arbitrary, but it can be made type safe. My idea was to use 
getRoleObject( $name, $type = null ) to perform an optional check against $type.

In addition, the RoleManager doesn't have to be a hash. It could also 
instantiate objects on demand. With a plain hash, we would not have the freedom 
to do that.


TASK DETAIL
  https://phabricator.wikimedia.org/T118860

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: daniel
Cc: mkroetzsch, adrianheine, hoo, thiemowmde, aude, Jonas, JanZerebecki, 
JeroenDeDauw, Aklapper, StudiesWorld, daniel, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T118500: [Task] Split RDF mapping code into separate classes per type

[gerritbot]

gerritbot added a comment.

Change 252026 merged by jenkins-bot:
Split SimpleValueRdfBuilder and ComplexValueRdfBuilder

https://gerrit.wikimedia.org/r/252026


TASK DETAIL
  https://phabricator.wikimedia.org/T118500

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: daniel, gerritbot
Cc: Lydia_Pintscher, Aklapper, daniel, gerritbot, Smalyshev, hoo, Tobi_WMDE_SW, 
Wikidata-bugs, aude, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T115112: Hide deprecated statements by default

[Nikki]

Nikki added a comment.

I started a new section on the project chat page: 
https://www.wikidata.org/wiki/Wikidata:Project_chat#The_meaning_of_the_deprecated_rank


TASK DETAIL
  https://phabricator.wikimedia.org/T115112

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Nikki
Cc: StudiesWorld, Lydia_Pintscher, Mineo, Nikki, Aklapper, Snaterlicious, 
thiemowmde, adrianheine, Liuxinyu970226, Bene, MGChecker, Ricordisamoa, 
Wikidata-bugs, aude, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Project Column] T112755: [Task] Add support for SnakFormatter factory callbacks to DataTypeDefinitions

[daniel]

daniel moved this task to Doing on the Wikidata-Sprint-2015-11-17 workboard.

TASK DETAIL
  https://phabricator.wikimedia.org/T112755

WORKBOARD
  https://phabricator.wikimedia.org/project/board/1620/

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: daniel
Cc: Lydia_Pintscher, Aklapper, thiemowmde, hoo, JanZerebecki, aude, daniel, 
Liuxinyu970226, Bugreporter, Ricordisamoa, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T112755: [Task] Add support for SnakFormatter factory callbacks to DataTypeDefinitions

[daniel]

daniel added a project: Wikidata-Sprint-2015-11-17.

TASK DETAIL
  https://phabricator.wikimedia.org/T112755

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: daniel
Cc: Lydia_Pintscher, Aklapper, thiemowmde, hoo, JanZerebecki, aude, daniel, 
Liuxinyu970226, Bugreporter, Ricordisamoa, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Claimed] T112755: [Task] Add support for SnakFormatter factory callbacks to DataTypeDefinitions

[daniel]

daniel claimed this task.

TASK DETAIL
  https://phabricator.wikimedia.org/T112755

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: daniel
Cc: Lydia_Pintscher, Aklapper, thiemowmde, hoo, JanZerebecki, aude, daniel, 
Liuxinyu970226, Bugreporter, Ricordisamoa, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Retitled] T117201: [WD] Implement internal use KPI

[Addshore]

Addshore changed the title from "[WD] Implement internal use KPI (pages)" to 
"[WD] Implement internal use KPI".

TASK DETAIL
  https://phabricator.wikimedia.org/T117201

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Addshore
Cc: StudiesWorld, Lydia_Pintscher, Abraham, Aklapper, Wikidata-bugs, aude, 
Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Retitled] T64874: [Story] Statistics for Special:EntityData usage

[Addshore]

Addshore changed the title from "[Story] Statistics for Wikidata exports" to 
"[Story] Statistics for Special:EntityData usage".

TASK DETAIL
  https://phabricator.wikimedia.org/T64874

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Addshore
Cc: JAllemandou, Halfak, hoo, Addshore, Ricordisamoa, Aklapper, drdee, Tnegrin, 
QChris, ezachte, Lydia_Pintscher, daniel, Wikidata-bugs, aude, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T118860: [Tracking] Represent derived data in the data model

[mkroetzsch]

mkroetzsch added a comment.

@daniel As long as it works for you, this is all fine by me, but in my 
experience with PHP this could cost a lot of memory, which could be a problem 
for the long item pages that already caused problems in the past.

> But it requires the serialization and formatting code to depend on the lookup 
> services


I know that it's always nice in software architecture to reduce the number of 
dependencies (for all kinds of reasons). However, I don't see a strong reason 
why code that formats a sitelink should not depend on the facility that 
provides the URL to link to. When things have a conceptual dependency, it is 
not bad design to have a code dependency there as well. I don't think there is 
any reason to have duplicate code in either solution -- that's just a matter of 
coordinating work within the team (not saying it is easy, but architecture 
alone will not solve this ...).

> Relying on global state like that for conveniance is what MediaWiki is doing 
> all over the place, with horrible results for testability and modularity


The state would not be global (I was over-simplifying). Of course you would 
have a $db object that provides the access to the sites table. Reading from a 
table is a stateless operation, so there is no state (global or local) involved 
and you can indeed use static code if you like. But of course you could also 
use a Sites object like in WDTK. Regarding testing, I guess you already have a 
mock db connection object anyway (otherwise, how would you test db read 
operations ...). I don't see a reason why this solution should be any less 
modular or testable than what you propose. There is also no need to have any 
duplicate code.


TASK DETAIL
  https://phabricator.wikimedia.org/T118860

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: mkroetzsch
Cc: mkroetzsch, adrianheine, hoo, thiemowmde, aude, Jonas, JanZerebecki, 
JeroenDeDauw, Aklapper, StudiesWorld, daniel, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T48643: [Story] Dispatching via delayed jobs (instead of cron script)

[ori]

ori added a blocked task: T118162: Wikibase dispatchChanges.php runs slow, 
creates an absurd amount of database connections.

TASK DETAIL
  https://phabricator.wikimedia.org/T48643

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: ori
Cc: Aklapper, Tobi_WMDE_SW, JanZerebecki, Wikidata-bugs, Abraham, Nemo_bis, 
Denny, aude, Ricordisamoa, Lydia_Pintscher, daniel, hoo, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T86755: [Bug] Preview gadget no longer working in new sitelinks UI

[Liuxinyu970226]

Liuxinyu970226 added a subscriber: Liuxinyu970226.

TASK DETAIL
  https://phabricator.wikimedia.org/T86755

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Liuxinyu970226
Cc: Liuxinyu970226, Billinghurst, Jonas, Bene, Ricordisamoa, thiemowmde, 
adrianheine, aude, Snaterlicious, Aklapper, Lydia_Pintscher, hoo, 
Wikidata-bugs, Sjoerddebruin, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T117533: DCAT-AP: Issued and modified should be typed

[EmidioStani]

EmidioStani added a comment.

Hello,

If I look at version 0.06: 
https://joinup.ec.europa.eu/asset/dcat_application_profile/asset_release/dcat-application-profile-data-portals-europe-final-draf

I see that they were already indicated as rdfs:Literal typed as xsd:date.

In 1.01: 
https://joinup.ec.europa.eu/asset/dcat_application_profile/asset_release/dcat-application-profile-data-portals-europe-final

they are already referred as rdfs:Literal typed as xsd:date or xsd:dateTime.


TASK DETAIL
  https://phabricator.wikimedia.org/T117533

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Lokal_Profil, EmidioStani
Cc: gerritbot, StudiesWorld, Aklapper, EmidioStani, Lokal_Profil, 
Wikidata-bugs, aude, Svick, Mbch331, jeremyb



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T118162: Wikibase dispatchChanges.php runs slow, creates an absurd amount of database connections

[gerritbot]

gerritbot added a project: Patch-For-Review.

TASK DETAIL
  https://phabricator.wikimedia.org/T118162

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: gerritbot
Cc: Tobi_WMDE_SW, ori, mobrovac, thiemowmde, aaron, jcrespo, gerritbot, daniel, 
aude, hoo, Lydia_Pintscher, Addshore, Aklapper, Joe, Wikidata-bugs, Mbch331, 
Krenair



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T118162: Wikibase dispatchChanges.php runs slow, creates an absurd amount of database connections

[gerritbot]

gerritbot added a comment.

Change 253889 had a related patch set uploaded (by Aude):
Close database connections in SqlChangeDispatchCoordinator

https://gerrit.wikimedia.org/r/253889


TASK DETAIL
  https://phabricator.wikimedia.org/T118162

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: gerritbot
Cc: Tobi_WMDE_SW, ori, mobrovac, thiemowmde, aaron, jcrespo, gerritbot, daniel, 
aude, hoo, Lydia_Pintscher, Addshore, Aklapper, Joe, Wikidata-bugs, Mbch331, 
Krenair



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Declined] T117200: [WD] Implement internal use KPI (infoboxes)

[Addshore]

Addshore closed this task as "Declined".
Addshore claimed this task.
Herald added a subscriber: StudiesWorld.

TASK DETAIL
  https://phabricator.wikimedia.org/T117200

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Addshore
Cc: StudiesWorld, Addshore, Lydia_Pintscher, Abraham, Aklapper, Wikidata-bugs, 
aude, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T118162: Wikibase dispatchChanges.php runs slow, creates an absurd amount of database connections

[ori]

ori added a comment.

In https://phabricator.wikimedia.org/T118162#1795369, @jcrespo wrote:

> - The cron jobs run as wikiadmin, which are on purpose not limited in 
> execution time, so there is no protection against them overflowing a database 
> server




In https://phabricator.wikimedia.org/T118162#1795406, @daniel wrote:

> - rewriting the dispatch logic to rely on the job queue has long been on the 
> todo list, see T48643: [Story] Dispatching via delayed jobs (instead of cron 
> script) . It's not trivial to get 
> right, though.


Ok, so it sounds like we have:

- A very severe problem.
- Agreement on how to mitigate it.

@Lydia_Pintscher, could you please make this a priority? Especially since the 
sprint goal of checking if this has been resolved has just been accomplished 
for you by Jaime.


TASK DETAIL
  https://phabricator.wikimedia.org/T118162

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: ori
Cc: ori, mobrovac, thiemowmde, aaron, jcrespo, gerritbot, daniel, aude, hoo, 
Lydia_Pintscher, Addshore, Aklapper, Joe, Wikidata-bugs, Mbch331, Krenair



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T118162: Wikibase dispatchChanges.php runs slow, creates an absurd amount of database connections

[ori]

ori removed a project: Patch-For-Review.

TASK DETAIL
  https://phabricator.wikimedia.org/T118162

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: ori
Cc: ori, mobrovac, thiemowmde, aaron, jcrespo, gerritbot, daniel, aude, hoo, 
Lydia_Pintscher, Addshore, Aklapper, Joe, Wikidata-bugs, Mbch331, Krenair



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T118463: [Story] Wikidata support for IFTTT

[Liuxinyu970226]

Liuxinyu970226 set Security to None.

TASK DETAIL
  https://phabricator.wikimedia.org/T118463

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Liuxinyu970226
Cc: Aklapper, Slaporte, Wikidata-bugs, aude, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T118162: Wikibase dispatchChanges.php runs slow, creates an absurd amount of database connections

[ori]

ori added a blocking task: T48643: [Story] Dispatching via delayed jobs 
(instead of cron script).

TASK DETAIL
  https://phabricator.wikimedia.org/T118162

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: ori
Cc: ori, mobrovac, thiemowmde, aaron, jcrespo, gerritbot, daniel, aude, hoo, 
Lydia_Pintscher, Addshore, Aklapper, Joe, Wikidata-bugs, Mbch331, Krenair



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T90870: selfcontained projects around Wikidata (tracking)

[Liuxinyu970226]

Liuxinyu970226 set Security to None.

TASK DETAIL
  https://phabricator.wikimedia.org/T90870

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Liuxinyu970226
Cc: Ricordisamoa, Qgil, mkroetzsch, Aklapper, Lydia_Pintscher, Wikidata-bugs, 
aude, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T118860: [Tracking] Represent derived data in the data model

[mkroetzsch]

mkroetzsch added a subscriber: mkroetzsch.
mkroetzsch added a comment.

Structurally, this would work, but it seems like a very general solution with a 
lot of overhead. Not sure that this pattern works well on PHP, where the cost 
of creating additional objects is huge. I also wonder whether it really is good 
to manage all those (very different!) types of "derived" information in a 
uniform way. The examples given belong to very different objects and are based 
on very different inputs (some things requiring external data sources, some 
not). I find it a bit unmotivated to architecturally unify things that are 
conceptually and technically so very different. The motivation given for 
choosing this solution starts from the premise that one has to find a single 
solution that works for all cases, including some "edge cases". Without this 
assumption, one would be free to solve the different problems individually, 
using what is best for each, instead of being forced to go for some least 
common denominator.

To pick just one example, consider the (article) URL of a SiteLink. To create 
it, one needs to have access to the content of the sites table. In WDTK, we 
encapsulate the sites table in an object (called Sites). To find out the URL of 
a SiteLink, one has to call a method of the Sites object (called 
getArticleUrl() or something), which takes a SiteLink as an input. This design 
is simple and efficient, uses no additional memory for storing new objects or 
values, and clearly locates the responsibility for computing this information 
(the Sites table). In a single-site setting (like you have in PHP), there is 
only one sites table, and you can access it statically, so the caller does not 
even need to have a reference to a Sites object as in WDTK. I therefore don't 
see any benefit in creating a role object for this simple task. It's just more 
indirection, without any convenience for the software developer or any gain in 
performance.

The situation is similar in several of the other cases mentioned. In the end, 
this is a choice for PHP development, which won't affect my work, so I'll leave 
it to you, but it seems you are making your life harder than necessary by going 
for a complicated solution instead of several simple solutions. There is only 
going to be a small number of different kinds of "derived data" ever, and there 
is hardly any place where such data is used in a way that does not need to 
understand its meaning (mainly for serialization).

For JSON exports of such data, I don't think this approach would make sense 
(but I suppose this is not intended here). There, one would simply use optional 
keys for including additional data. Likewise for RDF, where one would not want 
to introduce additional "role" objects that create another layer of indirection 
to access derived values (of course, RDF has a tradition of dealing with 
derived values, and nobody expects special structures there). I suppose that 
this proposal has nothing to do with JSON or RDF, but just to be sure we are on 
the same page.

The term "data model" is a bit over-used in our context -- maybe it would make 
sense to indicate in this bug report that it is specific to the object model 
used in the PHP implementation, and has no implications for other 
implementations or export formats.


TASK DETAIL
  https://phabricator.wikimedia.org/T118860

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: mkroetzsch
Cc: mkroetzsch, adrianheine, hoo, thiemowmde, aude, Jonas, JanZerebecki, 
JeroenDeDauw, Aklapper, StudiesWorld, daniel, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T118162: Wikibase dispatchChanges.php runs slow, creates an absurd amount of database connections

[jcrespo]

jcrespo added a comment.

> Now Jynus sais that he doesn't believe that fix is going to help our 
> situation. I'm curious about why he believes that.


Connection re-use does not work if you open 900 connections at the same time 
every 3 minutes. I have been saying that for a long time. If a DBA has to 
explain connection reuse vs pool of connections... :-/

> We could just as well place the locks for all client wikis on the wikidata 
> master db. Then there should be no reason to connect to the client database 
> at all (assuming the job queue is not using mysql).


Please don't. You are moving the problem from one server to another (and a more 
critical server). A good start would be to close connections as soon as they 
are not needed anymore- instead of idling them. Whatever you do, please do not 
test it in production.


TASK DETAIL
  https://phabricator.wikimedia.org/T118162

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: jcrespo
Cc: Tobi_WMDE_SW, ori, mobrovac, thiemowmde, aaron, jcrespo, gerritbot, daniel, 
aude, hoo, Lydia_Pintscher, Addshore, Aklapper, Joe, Wikidata-bugs, Mbch331, 
Krenair



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T118162: Wikibase dispatchChanges.php runs slow, creates an absurd amount of database connections

[aude]

aude added a comment.

from irc:

  05:33 < aude> jynus: would it be worth to backport and deploy 
https://gerrit.wikimedia.org/r/#/c/252267/ ?
  05:34 < aude> would be really good to know that this helps or not (or how 
much)
  05:34 < jynus> I do not think that will work at all


TASK DETAIL
  https://phabricator.wikimedia.org/T118162

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: aude
Cc: ori, mobrovac, thiemowmde, aaron, jcrespo, gerritbot, daniel, aude, hoo, 
Lydia_Pintscher, Addshore, Aklapper, Joe, Wikidata-bugs, Mbch331, Krenair



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T117533: DCAT-AP: Issued and modified should be typed

[Lokal_Profil]

Lokal_Profil added a comment.

To be clear I actually believe this is only needed to be compliant with v. 1.1. 
The version we have been working with is 1.0 so there might be more differences 
which should be implemented for full compliance with 1.1.

That said I don't think it is a problem introducing it (the patch) already now.


TASK DETAIL
  https://phabricator.wikimedia.org/T117533

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Lokal_Profil
Cc: gerritbot, StudiesWorld, Aklapper, EmidioStani, Lokal_Profil, 
Wikidata-bugs, aude, Svick, Mbch331, jeremyb



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T118162: Wikibase dispatchChanges.php runs slow, creates an absurd amount of database connections

[daniel]

daniel added a comment.

@ori We do not have agreement on how to fix this. Dispatching via the job queue 
would certainly be good, but it would change nothing regarding the number 
databases the dispatch code needs to talk to. As far as I can see, it would do 
nothing to fix the current problem.

As far as I know, we are using core methods that are supposed to facilitate 
connection re-use. This was broken in core, and was fixed by Aaron. Now Jynus 
sais that he doesn't believe that fix is going to help our situation. I'm 
curious about why he believes that.

It would also be good to get an answer to the question I asked in 
https://phabricator.wikimedia.org/T118162#1796490. Basically, I see three 
possibilities: 1) I am misunderstanding what the relevant core methods 
inLoadBalancer do 2) I'm using them wrong 3) they are broken. It would be very 
useful to get some feedback at least on the question whether  
SqlChangeDispatchCoordinator::engageClientLock() and 
SqlChangeDispatchCoordinator::releaseClientLock() are doing something obviously 
wrong.

One possible fix to the connection issue is to change the locking mechanism. 
That would not be very hard to code, but annoying to deploy - we'd need to stop 
all dispatch scripts to make sure no old code runs in parallel with new code. 
This would also mean side-stepping the problem without understanding the cause. 
And I would really like to understand the cause.


TASK DETAIL
  https://phabricator.wikimedia.org/T118162

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: daniel
Cc: Tobi_WMDE_SW, ori, mobrovac, thiemowmde, aaron, jcrespo, gerritbot, daniel, 
aude, hoo, Lydia_Pintscher, Addshore, Aklapper, Joe, Wikidata-bugs, Mbch331, 
Krenair



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Subscribers] T118162: Wikibase dispatchChanges.php runs slow, creates an absurd amount of database connections

[Tobi_WMDE_SW]

Tobi_WMDE_SW added a subscriber: Tobi_WMDE_SW.

TASK DETAIL
  https://phabricator.wikimedia.org/T118162

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Tobi_WMDE_SW
Cc: Tobi_WMDE_SW, ori, mobrovac, thiemowmde, aaron, jcrespo, gerritbot, daniel, 
aude, hoo, Lydia_Pintscher, Addshore, Aklapper, Joe, Wikidata-bugs, Mbch331, 
Krenair



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T117421: [Story] Put identifiers into separate section in the UI

[thiemowmde]

thiemowmde added a comment.

What's wrong with `StatementSectionView` (singular, because it's for one 
section only), as already suggested? I suggest to simply stick to that.

The interface can be a general `StatementGrouper`, sure. If it's designed in a 
way that it could also support "group by property id" in the future, I do not 
have a problem with that.

> (basically a hash map from propertyId to StatementList)


Isn't this, the "group statements by property id" part, a solved problem?

> Another approach would be to ditch wbEntity, just follow the structure of the 
> DOM


I would not like this for one reason: It will then be impossible (or at least 
much harder) to have statements in the JS view that are not in the PHP view 
(for example, deprecated statements could be hidden behind a "more" button).


TASK DETAIL
  https://phabricator.wikimedia.org/T117421

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: thiemowmde
Cc: Lydia_Pintscher, Aklapper, Sjoerddebruin, Liuxinyu970226, Ltrlg, 
Daniel_Mietchen, Ricordisamoa, Legoktm, Pigsonthewing, Filceolaire, PKM, Laddo, 
Sannita, Addshore, Multichill, Bene, Tobi_WMDE_SW, Snaterlicious, thiemowmde, 
adrianheine, Micru, jayvdb, MGChecker, DSGalaktos, Agabi10, Zolo, 
Wikidata-bugs, aude, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T118162: Wikibase dispatchChanges.php runs slow, creates an absurd amount of database connections

[gerritbot]

gerritbot added a comment.

Change 253889 abandoned by Aude:
Close database connections in SqlChangeDispatchCoordinator

https://gerrit.wikimedia.org/r/253889


TASK DETAIL
  https://phabricator.wikimedia.org/T118162

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: gerritbot
Cc: Tobi_WMDE_SW, ori, mobrovac, thiemowmde, aaron, jcrespo, gerritbot, daniel, 
aude, hoo, Lydia_Pintscher, Addshore, Aklapper, Joe, Wikidata-bugs, Mbch331, 
Krenair



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Project Column] T116005: Switch limn-data irc metric to use wm-bot channel user count

[Addshore]

Addshore moved this task to ToDo on the WMDE-Analytics-Engineering workboard.

TASK DETAIL
  https://phabricator.wikimedia.org/T116005

WORKBOARD
  https://phabricator.wikimedia.org/project/board/1585/

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Addshore
Cc: Addshore, Aklapper, Wikidata-bugs, aude, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T110648: [Bug] high-ranking items seemed to have dropped significantly in Special:Search results

[dcausse]

dcausse added a comment.

A big +1.
As far as I know it should be pretty straightforward, you just need to 
implement 2 hooks (`CirrusSearchMappingConfig` and 
`CirrusSearchBuildDocumentParse`).
The profiles (we may want to create multiple profiles with different weights 
for testing purpose) can be added to wmf-config.

Then we will have to re-index (exactly what you have done for geo coordinates 
recently).


TASK DETAIL
  https://phabricator.wikimedia.org/T110648

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: dcausse
Cc: Sjoerddebruin, EBernhardson, aude, dcausse, Deskana, daniel, Mbch331, 
Aklapper, Lydia_Pintscher, Wikidata-bugs, Gryllida, jeremyb



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T118860: [Tracking] Represent derived data in the data model

[adrianheine]

adrianheine added a subscriber: adrianheine.
adrianheine added a comment.

That looks to me like a fancier and less understandable way of just having an 
`additionalData` hash on each data model object. Did I miss something?

  interface AdditionalDataSupport {
function getAdditionalData();
  }
  
  interface AdditionalData {
function hasData( $name );
function getData( $name, $type = null );
function addData( $name );
  }
  
  interface LinkTargetProvider {
function getLinkTargetUrl();
  }
  
  interface DataTypeProvider {
function getDataType();
  }
  
  interface DerivedValueProvider {
function hasDerivedValue( $name );
function getDerivedValue( $name );
  }

The Role Object Pattern doesn't help saying anything about the name of roles or 
the type of role objects as far as I see it. Just as a hash, it stores 
arbitrary things under arbitrary keys.


TASK DETAIL
  https://phabricator.wikimedia.org/T118860

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: adrianheine
Cc: adrianheine, hoo, thiemowmde, aude, Jonas, JanZerebecki, JeroenDeDauw, 
Aklapper, StudiesWorld, daniel, Wikidata-bugs, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T114723: Should be a cleaner way to enable banners on all namespaces

[Sumit]

Sumit added a project: Google-Code-In-2015.
Sumit set Security to None.

TASK DETAIL
  https://phabricator.wikimedia.org/T114723

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Sumit
Cc: Krenair, Aklapper, Jdlrobson, Wikidata-bugs, aude, Lydia_Pintscher, 
Mbch331, Jay8g



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Commented On] T114723: Should be a cleaner way to enable banners on all namespaces

[Sumit]

Sumit added a subscriber: Sumit.
Sumit added a comment.

Could be done as part of GCI-2015.


TASK DETAIL
  https://phabricator.wikimedia.org/T114723

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Sumit
Cc: Sumit, Krenair, Aklapper, Jdlrobson, Wikidata-bugs, aude, Lydia_Pintscher, 
Mbch331, Jay8g



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Created] T118937: Set relevant banner properties as an OutputPage property for api requests

[Sumit]

Sumit created this task.
Sumit added subscribers: Jdlrobson, Aklapper, Sumit.
Sumit added a project: Wikidata-Page-Banner.
Herald added a project: Wikidata.

TASK DESCRIPTION
  Setting the following banner properties as an OutputPage property will set 
that property in page_props table and enable querying for those properties 
through api:
  * filename
  * thumbnail url for specified width/height
  * width and height
  * origin

TASK DETAIL
  https://phabricator.wikimedia.org/T118937

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Sumit
Cc: Sumit, Aklapper, Jdlrobson, Wikidata-bugs, aude, Lydia_Pintscher, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Updated] T118937: Set relevant banner properties as an OutputPage property for api requests

[Sumit]

Sumit removed a project: Wikidata.
Sumit set Security to None.

TASK DETAIL
  https://phabricator.wikimedia.org/T118937

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Sumit
Cc: Sumit, Aklapper, Jdlrobson, Wikidata-bugs, Lydia_Pintscher



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs

[Wikidata-bugs] [Maniphest] [Changed Project Column] T110902: [Bug] Table of content too large on mobile Wikidata

[Tobi_WMDE_SW]

Tobi_WMDE_SW moved this task to Review on the Wikidata-Sprint-2015-11-17 
workboard.

TASK DETAIL
  https://phabricator.wikimedia.org/T110902

WORKBOARD
  https://phabricator.wikimedia.org/project/board/1620/

EMAIL PREFERENCES
  https://phabricator.wikimedia.org/settings/panel/emailpreferences/

To: Bene, Tobi_WMDE_SW
Cc: Jonas, Tobi_WMDE_SW, Liuxinyu970226, Bene, thiemowmde, adrianheine, 
Snaterlicious, Aklapper, Florian, MaxSem, Lydia_Pintscher, Moushira, gerritbot, 
Wikidata-bugs, aude, Mbch331



___
Wikidata-bugs mailing list
Wikidata-bugs@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-bugs