| cjwatson | wgrant: I'm giving up on the StormRangeFactory bit for now. I do actually now have something that appears to work - haven't tried with launchpadlib, but the next_collection_link entries have elaborate-looking memos with full dates in them. The tricky bit is that it breaks if you pass the "wrong" parameters, because e.g. BPN isn't in the resultset so SRF can't cope with a resultset ordered by BPN, and at the moment I'm inserting the ... | 11:08 |
|---|---|---|
| cjwatson | ... range factory in the interface so it doesn't get to be parameter-sensitive. | 11:08 |
| cjwatson | Maybe this is fixable with a DecoratedResultSet or something, but I've run past the end of my timebox for this. | 11:08 |
| cjwatson | I'll just push up something today that implements order_by_date without that. | 11:10 |
| wgrant | cjwatson: I think launchpadlib is a bit magical, since it supports slicing. | 11:11 |
| wgrant | But yeah, SRF for the default sort order is awkward. | 11:12 |
| wgrant | (and pointless, since it can't be sorted by an index) | 11:12 |
| cjwatson | Ooh, I hadn't noticed launchpadlib.testing.launchpad before. | 11:19 |
| cjwatson | Should probably convert cdimage to that. | 11:19 |
| cjwatson | (It has a much less general version of the same idea) | 11:19 |
| cjwatson | wgrant: Is binarypackagepublishinghistory__archive__datecreated__id__idx on dogfood yours? It's not in database/schema/. | 12:51 |
| cjwatson | wgrant: And I assume it would need to be created concurrently (and live)? | 12:56 |
| stub | It doesn't exist on production | 14:50 |
| stub | cjwatson: ^ | 14:50 |
| rgammon51_ | I am up to date today on Ubuntu 15.04 with all updates applied | 15:27 |
| rgammon51_ | My issue is with nfs server | 15:27 |
| rgammon51_ | There are NO messages on the mount -a, exportfs, server restart | 15:28 |
| rgammon51_ | and showmount shows no messages - no exports | 15:28 |
| jpds | rgammon51_: Surely this is a question for #ubuntu-server ? | 15:29 |
| rgammon51_ | No this is Desktop, not server | 15:29 |
| mapreri | rgammon51_: then this is a question for #ubuntu, but surely not for this channel | 15:30 |
| rgammon51_ | I am an individual working on my own computrers, not for abusiness | 15:30 |
| rgammon51_ | launcpad, said this one | 15:30 |
| mapreri | rgammon51_: this is for development of the launchpad service itself, not for project hosted there | 15:31 |
| cjwatson | stub: thanks | 15:34 |
| cjwatson | wgrant: I'm seriously tempted to not bother making a separate class for GitMergeProposal at all and just teach BranchMergeProposal to handle both, notwithstanding the confusing name. It'd need to gain a few columns for source/target/dependent GitRef instead of Branch and for commit OIDs instead of revnos, and some complicated constraints to make sure that you can't mix-and-match, and the UI would need to use different macros to ... | 15:40 |
| cjwatson | ... render revisions etc. But it's that or clone-and-hacking a huge pile of both DDL and code, only to need similar branch-or-ref stuff in all the tables that refer to BMP; having started to write out all the DDL, I'm not sure the latter approach actually gains us much. | 15:40 |
| cjwatson | That is, although we have an Asana task to split out a base class, I think we might be better off just having the same class handle both. | 15:40 |
| cjwatson | I admit that widening 200000-odd BMP columns might be interesting. I'm not sure that should force the design though. | 15:44 |
| cjwatson | Maybe not a problem since the new columns wouldn't have defaults. | 16:02 |
| cjwatson | wgrant: The decision to use (repository, path) as a natural primary key for GitRef makes it really inconvenient to reference it as an FK in other tables. Maybe we should rearrange that to have a normal id. | 16:12 |
| wgrant | cjwatson: BMP very explicitly must not use an FK to GitRef. | 23:11 |
| wgrant | cjwatson: Since refs will be deleted, while MPs must not. | 23:11 |
| wgrant | cjwatson: (oops, yes, that index was mine. got distracted writing that big reply so forgot to delete it) | 23:12 |
| wgrant | cjwatson: Widening BMP isn't an issue, as it's a small table and reasonably sensibly bounded. And it's already very wide. | 23:12 |
| wgrant | cjwatson: I'm all for reusing the table if you think it'll be more efficient. In fact I think it was you that convinced me not to, after your experience with not being able to share much code with your initial work. So go ahead. | 23:13 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!