LibraryFileAlias URL comes from wrong store
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Launchpad itself |
Fix Released
|
Low
|
Jeroen T. Vermeulen |
Bug Description
When rendering e.g. an icon, we use LibraryFileAlia
There is a subtle problem between the latter two. You'd expect http_url to ask getURLForAlias for "the URL for this LibraryFileAlias." But instead, it asks for "the URL for the LibraryFileAlias with this ID." So there's a redundant lookup for "the LibraryFileAlias with the same ID as this LibraryFileAlias." You don't normally notice this of course, because the right object is already cached.
But there is a case where you do notice. If the LibraryFileAlias was retrieved from the slave store but the current request uses the master store by default. Then you do get an extra database query, and on our precious master store—and it also bypasses any prejoining you might have done to get the slave-side LibraryFileAliases in the first place.
The solution: make FileDownloadCli
Related branches
- Steve Kowalik (community): Abstain (code*)
- Robert Collins (community): Approve
-
Diff: 622 lines (+223/-111)6 files modifiedlib/canonical/launchpad/database/librarian.py (+1/-1)
lib/canonical/librarian/client.py (+120/-58)
lib/canonical/librarian/ftests/test_web.py (+35/-29)
lib/canonical/librarian/interfaces.py (+9/-0)
lib/lp/testing/fakelibrarian.py (+7/-2)
lib/lp/testing/tests/test_fakelibrarian.py (+51/-21)
Changed in launchpad-foundations: | |
status: | New → In Progress |
importance: | Undecided → Low |
assignee: | nobody → Jeroen T. Vermeulen (jtv) |
milestone: | none → 10.10 |
Changed in launchpad-foundations: | |
status: | In Progress → Fix Committed |
tags: | added: qa-ok timeout |
tags: |
added: qa-ok removed: qa-needstesting |
tags: | removed: timeout |
Changed in launchpad-foundations: | |
status: | Fix Committed → Fix Released |
Fixed in stable r11526 <http:// bazaar. launchpad. net/~launchpad- pqm/launchpad/ stable/ revision/ 11526>.