/srv/irclogs.ubuntu.com/2019/04/25/#launchpad.txt

=== chihchun_afk is now known as chihchun
=== Eickmeyer[m] is now known as eickmeyer[m]
=== eickmeyer[m] is now known as Eickmeyer[m]
=== chihchun is now known as chihchun_afk
=== ricotz_ is now known as ricotz
rbasakcjwatson: to correctly cache my LP objects, I should probably key the cache on the logged in user, to prevent private objects being available to the wrong logins. Unless I assume that there will only ever be one login in the app. Looking for something to key on, I found ._root, which looks like it gives me the top level Launchpad object which should be sufficient. But that's internal. Do you have any08:05
rbasakrecommendation on this?08:06
=== zbr is now known as zbr|rover
cjwatsonrbasak: I wouldn't cache across logins at all08:23
cjwatsonrbasak: Why not just make the cache be per-process rather than persistent?08:23
cjwatsonrbasak: And if you log out (unusual for an API-using program but OK), clear the cache then08:24
rbasakcjwatson: it is per-process and not persistent already. But it's quite deep inside an internal library, so I was concerned that I'd leave a subtle bug in that library unless I key the cache by login08:24
cjwatsonrbasak: You could probably just key on the hash of the lp object itself.  Logging in is done by creating a new instance of that.08:27
cjwatsonThat is, instances of the Launchpad class08:27
rbasakI don't think that would work in this case.08:28
rbasakThe problem is that the object is different, which is where my problem is coming from in the first place.08:29
rbasakI am iterating over source_package_publication_history objects08:29
rbasakOn each of those, I fetch things like the distro_series attribute08:29
rbasakEach of those is resulting in an API round trip to fetch it (even if it comes back with Not Modified)08:29
rbasakHowever distro_series_link is the same every time, so that's what I'm keying my cache on (which works)08:30
cjwatsonI don't see how you can both cache across logins and not cache across logins.08:30
cjwatsonIf the instance of the Launchpad object is different then surely that indicates a fresh login (if perhaps the same user)08:30
cjwatsonSo why is that happening?08:30
rbasakEach source_package_publication_history object is different, as expected, right?08:31
rbasakHow do I get to the Launchpad object from that?08:31
rbasakI only found _root08:31
rbasakWhich is internal08:31
cjwatsonOh I see what you mean08:31
cjwatsonMeeting, back in 20 minutes or so08:31
rbasakack08:31
cjwatsonrbasak: I think using _root is your only option08:47
cjwatsonIt's technically private but in practice very stable08:47
rbasakOK. Thanks!08:57
rbasakFWIW, http://paste.ubuntu.com/p/rYnjwB5557/ is what I have now, which seems to work.08:59
cjwatsonLooks quite nice09:03
rbasakThanks!09:05
=== juliank is now known as juliank|dalek
=== juliank|dalek is now known as juliank
ricotzhi, afaics there are some ppa builds stuck at "purging the builddir" -- https://launchpad.net/~mozillateam/+archive/ubuntu/firefox-next/+build/16688179 -- most builds are stuck in https://launchpad.net/~mozillateam/+archive/ubuntu/firefox-next/+packages15:42
ricotzcjwatson, hi :), ^16:11
=== zbr is now known as zbr|rover
tjaaltonare ppa builders all busy/taken?17:08
tjaaltonoh, archive open.. maybe that's why17:19
=== corvus is now known as jeblair
=== jeblair is now known as corvus
acheronukcjwatson: hi. is buildd-manager or something like that poorly again?18:25
cjwatsonI'm not at home right now but I've requested a restart since it's probably that18:43
acheronukty18:44

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!