[02:56] wgrant: Thanks, that looks like excellent advice on db-index-bpph-datecreated. The COUNT(*) did actually come from a real query, but that's because I was using list() on the collection; not totally unreasonable since I wanted the whole collection anyway, but I'd forgotten that it concealed a race. [02:56] (And yes, I know it's a silly time. Fell asleep getting the children to bed and in a slightly odd state of sleepiness as a result; I'm going back to bed soon.) [02:56] Heh [02:57] cjwatson: The racy version probably wouldn't be too bad, but the fixes to make it non-racy should be pretty easy I think. [02:57] I agree. [03:02] Perhaps it makes sense to add a similar ordering parameter to getPublishedSources as well. We don't need it in this case, but it's easy to imagine, and it's better to keep APIs symmetric where they don't need to be asymmetric. [03:03] cjwatson: I don't know, anyone using the API would probably be upset by such consistency or sense. [03:04] The LP API just wouldn't feel the same without smatterings of exact_match=False and the like. [03:04] We should be applying PHP design patterns? [03:04] Precisely. [03:04] Noted. [03:06] I should probably Stormify getAPB too before my eyes bleed too much. [03:07] IIRC it has very few internal callsites, so it should be easy enough to port. [03:07] Two. [03:07] (One of which is annoyingly *almost* test-only.) [03:08] Oh, well, two for _getBinaryPublishingBaseClauses, probably more for getAllPublishedBinaries. [03:40] pit y console.log(Y.Node.DOM_EVENTS.key.eventDef.KEY_MAP); [03:40] err pity. Only 5 keys in that map [03:43] kind of loath to use the charCodes in tests, but adding a new KeyEvent map there seems redundant. [03:43] wgrant: anyhow, have some integration tests for nav, and found a bug in the process which was nice. [03:44] wgrant: afaict we don't have js unittests? [03:47] blr: There aren't many proper unit tests, no. [03:48] wgrant: a bit more noise in the diff now, I fixed some js lintiness. [03:50] wgrant: if we can modernised our js build process, we could consider adopting something like karma. [03:50] have used that in the past and it is rather good. [03:53] did you have a chance to look at babel? [03:53] It sounded too good to be true :P [03:53] hah right [03:54] wgrant: I have a friend at mozilla, I should ask him about it - they're using it apparently. [04:02] wgrant: transitioning to something like webpack/babel/gulp seems sensible, but I'm not certain how we do that while also supporting yui3. Suspect it is going to be messy. [04:08] I suspect it would be reasonably possible to use webpack to load YUI3, but it won't be totally trivial. [04:18] something to experiment with a bit later perhaps. [04:19] Yep. [05:04] tsk [05:25] wgrant: for some reason lp-land wants to uses a curses browser, but firefox is set as my x-www-browser alternative - have you seen that? [05:25] blr: You're not accidentally running it inside a container? [05:25] err... maybe? >.> [05:25] thanks [05:27] Heh, I do that all the time... [11:57] wgrant: Hm, inserting StormRangeFactory here is less than trivial; all the uses to date have been in browser code, not webservice. I think lazr.restful might need some extensions here - perhaps by adding a range_factory to ICollection? [12:06] And maybe an optional parameter to export_as_webservice_collection [12:13] cjwatson: Hmm, you may well be right... [12:14] It's also possible that launchpadlib won't like it. [12:14] I remember we ran into this years ago, but we may not have solved it. [12:14] I can start in on the lazr.restful changes, though I have the sense of a rabbit-hole [12:15] Quite. [12:15] All I want is ddebs damnit [12:16] Still, most of the benefit can be gained without SRF [12:16] We can't run it reliably without SRF, can we? [12:16] Because the traversal will be shallow with the collection sanely ordered. [12:16] Because the memos will be wrong [12:16] Oh, yeah. [12:17] Although the batch is only going to be shuffled backwards [12:17] Yeah, in this case it's probably safeish. [12:17] It can be shuffled the other direction if things get deleted. [12:17] That is, the ordering means that the worst case is that elements 76-150 (say) in the batch were previously elements 75-149 or earlier [12:17] (which they often do, nowdaays) [12:17] Oh? Bah, good point. [12:18] So I think I need to at least try to attack this. [12:18] The alternative, of course, is to let the status filter be omitted. [12:19] We arguably want that anyway [12:19] Quite. [12:19] For more reliable retracing, ddeb-retriever wants to catch up with everything, not just what's Published right now [12:19] Well, that will be achieved eventually with the retracers not using ddebs.u.c at all. [12:19] Yes, but not for a while. [12:20] But I've long wanted a getPublishedBinaries that was designed to be used. [12:20] How about I timebox this: I'll spend until end of day today seeing how far I get with inserting SRF [12:21] Works for me. [12:21] If the madness continues I can give up and go for the stupid and duplicative approach. === danilo__ is now known as danilos [13:34] wgrant: Could I have PyPI access to lazr.batchnavigator, please, so that I can finish up bug 872086 while I'm buried in all of this anyway? [13:34] Bug #872086: Distribution:+ppas and Distribution:+questions issue unlimited queries when memo=0&direction=backwards [13:34] wgrant: Maybe also lazr.restful [13:38] cjwatson: You're cjwatson? [13:43] wgrant: Yes. [13:43] cjwatson: Done. [13:43] Thanks [16:36] wgrant: Looking harder, I'm not sure what you mean about the status filter. It can be omitted already and you get publications with any status. [16:37] wgrant: I think I have a first cut at the lazr.restful changes, although I'm sufficiently unfamiliar with the lazr.restful test suite that I won't be especially confident in them until I've tried hooking that up to LP. [22:23] cjwatson: Oh, forgot status was optional.