Merge lp://staging/~elachuni/ubuntu-webcatalog/metadata_api into lp://staging/ubuntu-webcatalog
| Status: | Merged | ||||
|---|---|---|---|---|---|
| Approved by: | Anthony Lenton | ||||
| Approved revision: | 171 | ||||
| Merged at revision: | 171 | ||||
| Proposed branch: | lp://staging/~elachuni/ubuntu-webcatalog/metadata_api | ||||
| Merge into: | lp://staging/ubuntu-webcatalog | ||||
| Diff against target: |
185 lines (+89/-2) 4 files modified
src/webcatalog/api/handlers.py (+23/-1) src/webcatalog/api/urls.py (+7/-0) src/webcatalog/tests/test_api.py (+30/-1) src/webcatalog/tests/test_handlers.py (+29/-0) |
||||
| To merge this branch: | bzr merge lp://staging/~elachuni/ubuntu-webcatalog/metadata_api | ||||
| Related bugs: |
|
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Michael Nelson (community) | Approve | ||
|
Review via email:
|
|||
Commit message
Added a public extensible metadata api.
Description of the change
This branch adds a basic public extensible app metadata api.
This is a bit of preliminary work for bug #1052103, which is in turn a bit of preliminary work to provide recommendations based on installed-apps.
I first wanted to provide the department data for each app, but this proved to be tricky as it would require digging into a Many-to-many relation, and until we can use Django 1.4's prefetch-related that means either a bit of hand-crafted postgresql-specific SQL, or denormalizing the schema to duplicate the list of departments on each app as a comma-separated field, or performining one request per app.
Instead, I can get kind of the same information out of the categories field, and that is populated correctly both for apps from apt-cache and myapps, so I went with that instead. No migration needed.
14:01 < noodles> achuni: re your MP (sorry if we've chatted about this before), you've added the gzip_page decorator to your new handler - isn't that something we should do for the whole api (well, shouldn't apache be doing that whenever the client accepts gzip?)
14:02 < achuni> noodles: re: doing it in apache vs. the app, last time we discussed it the advantage was control & configurability, and both will end up calling basically the same underlying C library, so not much performance loss
14:03 < noodles> achuni: what would we not want to gzip (other than when client doesn't accept gzip)
14:03 < achuni> noodles: re: doing it across the whole api, it's the only call so far that return any amount of data
14:03 < noodles> achuni: sure, it just seems like a decision our code shouldn't even have to make. But great - tests look great :) +1
14:05 < achuni> noodles: yep, I don't think we lose much by enabling it across the board
14:05 < achuni> s/much/anything/
14:10 < noodles> achuni: Where do we actually set categories for an application? I thought it'd been removed in favour of departments, and can't see it in the import_
14:15 < achuni> noodles: in import_
14:15 < achuni> noodles: it instantiates a ArchiveApplicat
14:15 < achuni> noodles: that populates all fields in Application, except a few listed explicitly
14:16 < noodles> achuni: right, which is why my grep didn't find categories there. Sweet.
14:16 < achuni> yep