[00:17] <StevenK> wgrant: http://pastebin.ubuntu.com/1390509/
[00:32] <wgrant> StevenK: searchable_names, maybe? Not sure
[00:33] <wgrant> That otherwise sounds reasonable
[00:33] <wgrant> Hmm
[00:33] <wgrant> Though hmm
[00:33] <wgrant> This will sometimes end up too long for pg_trgm to cope with, I suspect :(
[00:34] <StevenK> Oh? pg_trgm has a limit?
[00:34] <wgrant> Indices in general are sort of limited. Try inserting a very large string and see what happens
[00:35] <wgrant> It will probably object
[00:39] <StevenK> INSERT 0 1
[00:40] <StevenK> That's inserting a row into packageupload with distroseries = 1, pocket = 0, archive = 1 and search_text = 'a'*50000
[00:40] <wgrant> Huh
[00:40] <wgrant> Interesting.
[00:40] <wgrant> ALthough it may optimise because it's all a
[00:41] <StevenK> I'm not sure about typing out 50000 random characters
[00:41] <StevenK> :-)
[00:42] <wgrant> Anyway, I must be off for a few hours
[00:42] <wgrant> If it works, then great ;)
[00:42] <wgrant> :)
[00:42] <StevenK> wgrant: Well, how about we cook up a query to fetch the BPNs for a large source and set search_text to that and see what happens
[08:49] <adeuring> good morning
[11:35] <adeuring> frankban: could you pease review this MP: https://code.launchpad.net/~adeuring/launchpad/lp-view-for-timelneproductseries/+merge/136374 ?
[11:36] <frankban> adeuring: sure, on it in a minute
[11:36] <adeuring> frankban: thanks, no hurry (enjoy lunch!)
[13:24] <rick_h_> adeuring: r=me on the review, I grabbed it frankban
[13:24] <adeuring> rick_h_: thanks!
[13:36] <frankban> rick_h_: thanks
[15:08] <czajkowski> jtv1: there are two of you :) jtv
[15:08] <rick_h_> abentley: ping, I'm about to get my car but while I pay/head home do you have time to look over my storm-ization of this https://pastebin.canonical.com/79162/ ?
[15:09] <abentley> rick_h_: certainly:
[15:09] <rick_h_> abentley: I've still got to get tests going against it, but I wanted to do a side vs side write and wonder if anything jumps out at you on it
[15:09] <rick_h_> ok, going to be afk for a little bit. Will catch up.
[15:09] <rick_h_> thanks!
[15:11] <jcsackett> frankban, rick_h_: can one of you take a look at https://code.launchpad.net/~jcsackett/launchpad/404-not-403-for-private-blueprints/+merge/136442
[15:23] <frankban> jcsackett: on it
[15:28] <jtv> czajkowski: setting up  a new system...
[15:28] <czajkowski> jtv: ahh I see
[15:28] <czajkowski> jtv: I had a user of lp translations who was unsure how to progress on an issue so asked them to mail lp-users
[15:29] <jtv> That's going to be a bit broad.  :/
[15:33] <abentley> jtv: For private projects, we need to ensure there are no translations.  It seems we need to ensure translations are disabled, there are no POTemplates, no ProductSeries has automatic imports.  Am I missing anything?
[15:36] <jtv> abentley: that almost covers it... ideally you don't want anything on its translations import queue either.
[15:36] <abentley> jtv: Okay, I'll include that.
[15:37] <czajkowski> jtv: which part is going to be broad...
[15:37] <jtv> czajkowski: it's going to cover a lot of people.
[15:38] <czajkowski> ah I see
[15:42] <jcsackett> frankban: thanks!
[15:45] <frankban> jcsackett: my pleasure
[15:48] <rick_h_> ok, back yay for new tires
[16:02] <abentley> rick_h_: So, the first thing is that I recommend using lp.blueprints.model.specification.get_specification_filters
[16:02] <abentley> rick_h_: If for some reason you can't, I still recommend using fti_search rather than specifying it manually.
[16:03] <rick_h_> abentley: ah ok, I thought I had seen something like that but when I searched a couple of other models found it done that way
[16:03] <abentley> rick_h_: It's only a month or so old.
[16:03] <rick_h_> ah, makes sense then
[16:05] <rick_h_> and yea, get_specification_filters looks good as well. Thanks
[16:05] <abentley> rick_h_: Also, using ProductSet.getProductPrivacyFilter does not address your bug, because that doesn't ensure the user can view the specification.  Use visible_specification_query
[16:06] <rick_h_> ok, I was going to ask about that as it seemed a bunch of magic for storm to auto join/etc to get those filters to work
[16:09] <abentley> rick_h_: Storm doesn't have a particularly clean way of doing composition with left joins, but using left joins was by far the most efficient way, so visible_specification_query returns both a list of tables and a list of clauses.
[16:10] <rick_h_> abentley: right, so the tables goes into a using() and looks like it's got specifications so should be complete there
[16:10] <rick_h_> is that prejoin right? It was the same api as used before, but that seems to match what I could find in the api docs for storm
[16:11] <abentley> rick_h_: AFAIK, Storm does not support prejoins, so I was surprised to see it there.  Have you tested it?
[16:12] <rick_h_> no, not yet.
[16:13] <rick_h_> abentley: ah, it's on the api under SQLObjectResultSet :/
[16:13] <abentley> rick_h_: Okay, so I would expect that to fail.  There are workarounds you can steal, though, if you need to support prejoins.
[16:13] <rick_h_> abentley: ok yea. I'll look for some more examples then.
[16:13] <rick_h_> thanks for the quick sanity check and pointers to the helper methods
[16:16] <abentley> rick_h_: See blueprints.model.specification.HasSpecificationsMixin._preload_specifications_people
[16:17] <abentley> rick_h_: But see if you need 'em first.  A lot of prejoins are premature optimizations.
[16:17] <rick_h_> abentley: well right now I"m just trying to port over all the old code to storm and it was there as a prejoin if the argument was passed in
[16:18] <rick_h_> I can look for uses and go from there
[16:20] <rick_h_> bah, it's default True so it just might be left out of the arg clause
[16:22] <rick_h_> man...that preload_specifications_people is fugly
[17:46] <czajkowski> rick_h_: you there?
[17:48] <rick_h_> czajkowski: yepper
[17:49] <czajkowski> rick_h_: whats the link to the bugs ye have opened for P bp ?
[17:50] <rick_h_> translation: links to bugs we're working on around private blueprints?
[17:50] <czajkowski> yes sorry
[17:50] <czajkowski> :/
[17:50] <rick_h_> czajkowski: can you see our kanban board?
[17:50] <czajkowski> really have to stop shortening words
[17:50] <rick_h_> single letter variable names are bad :P
[17:50] <czajkowski> yes
[17:50] <czajkowski> and yes I can
[17:50] <czajkowski> so just look there
[17:51] <rick_h_> yea, that'll be the most up to date.
[17:51] <czajkowski> grand job
[17:51] <rick_h_> if it's not there then we're not aware/it snuck in so let us know
[17:51] <czajkowski> thanks
[19:15] <rick_h_> abentley: do you recall the use of Compile to dump a resultset query?
[19:16] <abentley> rick_h_: You should use Store.compile, but you should really configure postgres to emit queries in the log, because that shows the substituted variables.
[19:16] <rick_h_> yea, you're right
[19:17] <abentley> rick_h_: log_statement='all' in /etc/postgresql/9.1/main/postgresql.conf will do the trick.
[19:17] <rick_h_> abentley: rgr, updating now. thanks for the reminder to quick doing it the hard way
[19:17] <abentley> rick_h_: np.
[21:30] <wgrant> rick_h_: Do you know about the LP_DEBUG_SQL=1 environment variable, and the convert_storm_clause_to_string function?
[22:05] <sinzui> wgrant, https://code.qastaging.launchpad.net/~sinzui/impressive/lirc-0/+merge/29161/++oops++
[22:34] <sinzui> wgrant, StevenK, does this relate to bug 62976
[22:34] <_mup_> Bug #62976: Soyuz should not allow duplicated packages in NEW/UNAPPROVED queue <boobytrap> <lp-soyuz> <oops> <rfwtad> <soyuz-upload> <Launchpad itself:Triaged> < https://launchpad.net/bugs/62976 >
[22:39] <StevenK> wgrant: http://pastebin.ubuntu.com/1393012/
[22:41] <cjwatson> ah, well that might make my long-stalled approved branch more sensible ...
[22:42] <StevenK> cjwatson: That was the plan
[22:42] <StevenK> If it's searchable_names you're talking about.
[22:42] <StevenK> wgrant and I came up with a plan yesterday
[22:42] <StevenK> Not quite as good as The Brilliant Disclosure Plan, but still a good one
[22:45] <wgrant> cjwatson: Yeah, we had a +queue search timeout bug, so I decided we might as well fix that and yours once and for all
[22:47] <wgrant> StevenK: https://bugs.launchpad.net/bugs/163997
[22:47] <_mup_> Bug #163997: Subject of Soyuz binaryful acceptance emails, emails, emails, emails, emails, emails stutter <lp-soyuz> <Launchpad itself:Won't Fix> < https://launchpad.net/bugs/163997 >
[22:47] <wgrant> sinzui, StevenK https://www.youtube.com/watch?v=H3OJvbnTnE8
[22:47] <StevenK> wgrant, sinzui: http://sphotos-c.ak.fbcdn.net/hphotos-ak-prn1/16056_378137315607151_2018832644_n.jpg
[22:53] <cjwatson> StevenK,wgrant: Right.  Every so often I've been looking at that branch and contemplating inserting a feature flag, and then giving up in despair at how horrible it is.
[22:54] <StevenK> I am looking forward to making IPackageUploadSet.getAll() a shadow of its former self.
[23:40] <StevenK> wgrant: The query is still baking?
[23:43] <wgrant> StevenK: Yeah
[23:55] <wgrant> StevenK: Something like http://paste.ubuntu.com/1393183/
[23:55] <wgrant> Although we also need to do something with PCJs, I guess
[23:57] <StevenK> I don't think you need array_agg for the source, there will be at most one source
[23:57] <wgrant> Oh, there's actually a UNIQUE constraint for that, indeed
[23:58] <wgrant> I know we only ever have one, and other stuff will break if there's more than one, but thought I might as well cope :)
[23:58] <wgrant> But there's indeed a constraint