[09:50:33] <gehel>	 Lunch
[10:09:41] <zpapierski>	 yay, I made the test work for query completion suggester! unfortunately I still don't know what it does (mostly)
[10:11:13] <dcausse>	 :)
[10:12:20] <zpapierski>	 I'm mostly joking - I'm somewhat convinced that it load the suggest profiles and runs the queries for profiles that match and checks if number of queries matches. In my case it's a single query (I only defined a single profile), so I'm not sure that the test makes sense
[10:13:06] <zpapierski>	 but I'm not about to remove only test I understand 
[10:14:49] <zpapierski>	 ok, I made the second test pass and now I'm suspicious
[10:16:47] <dcausse>	 the test does not contact elastic directly it provides a mocked response statically from a @dataProvider method
[10:17:12] <dcausse>	 you might want to capture the response using the index you made to adapt the test
[10:19:31] <zpapierski>	 I thought I did, but I have a hard time believing that it worked just like that
[10:19:41] <zpapierski>	 I'm not that lucky
[10:31:48] <dcausse>	 yes... I'd feel suspicious as well :)
[10:31:53] <dcausse>	 lunch
[11:32:20] <zpapierski>	 ah, my suspicions were correct - it didn't actually return suggestios and expected to get zero as well, don't know yet why
[11:35:25] <zpapierski>	 ok, nvm - it's 0 only for a single case
[11:38:07] <zpapierski>	 meal 3 break and relocation
[12:58:57] <zpapierski>	 I'm giving up, it works correctly, somehow
[13:01:01] <zpapierski>	 although, despite the name, it doesn't test the QueryCompletionSuggester at all
[13:13:22] <zpapierski>	 dcausse: is there anything that tests title completion? some integration test I'm missing?
[13:14:38] <dcausse>	 it's tested with phpunit-integration tests (the one you probably ported) and with "browser tests" (actual integration tests ran by cindy)
[13:15:15] <zpapierski>	 I see, so I'll get to test it when frontend part is completed, fair enough
[13:16:07] <dcausse>	 we try to write "real" unit tests now, it's been a while since we added new integration tests managed by cindy
[13:16:18] <zpapierski>	 the test name I  ported is a misnomer - it tests what TitleCompletionSuggester uses, not the class itself
[13:17:35] <dcausse>	 yes probably as the class itself is mostly glue code to Elastica which would require tons of mocking to test without elastic
[13:18:15] <zpapierski>	 I have no issue with that (given a functional browser test)
[13:20:53] <dcausse>	 you could also simply exposes all this through a new API module, see includes/Api/ for how to create new API endpoints
[13:21:45] <zpapierski>	 how will that help me with the testing?
[13:23:54] <dcausse>	 "browser tests" are mostly tests through the various APIs very few are running a browser
[13:24:02] <zpapierski>	 ah, I see
[13:24:29] <zpapierski>	 so if I have this done, I'll be able to create a "browser" test
[13:24:36] <zpapierski>	 those names are really something :)
[13:25:02] <dcausse>	 yes...
[14:08:19] <ebernhardson>	 i'm bad at renaming things :P The first thing i did in discovery platform was change all the browser tests from using a browser to using api to make them run in a reasonable time :P
[14:08:29] <ebernhardson>	 err, discovery department
[14:17:21] <dcausse>	 hm.. with scala I can't seem to understand how to write hashCode & equals properly esp with inheritance
[14:18:09] <dcausse>	 since foo == bar is equivalent to foo.equals(bar) AFAIU
[14:19:38] <dcausse>	 does super == that equivalent to super.equals(that) ?
[14:20:37] <dcausse>	 well it does not even compile... 
[14:22:30] <zpapierski>	 I'm not sure what you're trying to achieve here - how is super logically different from the  obbject itself, equality wise?
[14:24:13] <ebernhardson>	 zpapierski: super has access to the private state to do equality checks with?
[14:24:17] <dcausse>	 parent class has a field that if not tested using super.equals would make two different object identical 
[14:29:28] <zpapierski>	 ah,  I get it 
[14:36:09] <zpapierski>	 anyway, limitation of the language maybe? I don't know if super is actually treated as an object reference, because if would, to what exactly?
[14:36:21] <zpapierski>	 I'm assuming without it == makes no sense
[14:45:00] <zpapierski>	 on the other hand, this works - super.==(that)
[14:45:24] <dcausse>	 hu
[14:46:05] <dcausse>	 scala is evil (or inheritance)
[14:46:21] <zpapierski>	 both, let's not limit ourselves
[14:47:24] <zpapierski>	 it's actually true for all infix expressions and super
[14:47:24] <zpapierski>	 https://stackoverflow.com/questions/42952103/scala-infix-operator-for-super-cant-be-called-infix
[14:48:52] <zpapierski>	 it wasn't about reference it seems, super is simply not an expression and language syntax requires expressions on left-hand operands of infix operation
[14:49:16] <zpapierski>	 still weird
[19:11:30] <mpham>	 i recall WCQS being reloaded from weekly dumps currently; how will this change once it is in production?
[19:15:49] <ebernhardson>	 I'm not entirely sure, i would suspect that when first switched over it will be dumps, switching to streaming updater once thats deployed. but i dunno :S
[19:18:06] <mpham>	 would the streaming updater's performance on WDQS (i.e. 100 edits/s or whatever it is) be the same/comparable for WCQS? 
[19:29:29] <ebernhardson>	 I'd expect wcqs to have lower update rates than wdqs, if it works on wikidata it should have enough perf for commons
[20:40:52] <dcausse>	 wikidata is ~50% of the total edit rate (all projects combined), so yes commons is likely a lot less