Closed Bug 1343239 Opened 8 years ago Closed 4 years ago

Cleanup the /jobdetails/ API endpoint and usage by the UI

Categories

(Tree Management :: Treeherder: API, enhancement, P1)

enhancement

Tracking

(Not tracked)

RESOLVED INVALID

People

(Reporter: emorley, Assigned: sclements)

References

(Blocks 2 open bugs)

Details

Attachments

(1 file)

Issues: 1) The UI makes calls like: http://localhost:8000/api/jobdetail/?job_guid=3edb9a197bb1a1473bdc0d11494a986b8ece6748 ...rather than using job_id which is on the table itself 2) The endpoint supports both `job_guid` and `job__guid` as parameter names, which is fine for transition, but can be cleaned up now 3) That said, I think we should just unsupport both passing job_guid and returning the guid in the response, which would avoid needing to include `job` in select_related too. 4) The queryset unnecessarily includes `repository` in select_related when that table is only used for filtering and not referenced in the response. 5) That said, I can't see a valid use case for filtering by `repository` (seeing as one of job_guid/job_id is mandatory anyway), so we should just remove support for it. Just to give an example: http://localhost:8000/api/jobdetail/?job_guid=3edb9a197bb1a1473bdc0d11494a986b8ece6748 returned: { "next": null, "previous": null, "results": [ { "job_id": 5776, "job_guid": "3edb9a197bb1a1473bdc0d11494a986b8ece6748", "title": "artifact uploaded", "value": "resource-usage.json", "url": "http://mozilla-releng-blobs.s3.amazonaws.com/blobs/mozilla-inbound/sha512/49081b45cae996004ef1f6a65e39c2ea6adab3bf9ce0968113567f057532365d86e3277791c193b36e2244b15ee7cf63d000f4d9bd3786d9f352aec9f476e488" }, ... Via this: SELECT job_detail.id, job_detail.job_id, job_detail.title, job_detail.value, job_detail.url, job.id, job.repository_id, job.guid, job.project_specific_id, job.coalesced_to_guid, job.signature_id, job.build_platform_id, job.machine_platform_id, job.machine_id, job.option_collection_hash, job.job_type_id, job.product_id, job.failure_classification_id, job.who, job.reason, job.result, job.state, job.submit_time, job.start_time, job.end_time, job.last_modified, job.running_eta, job.tier, job.push_id, repository.id, repository.repository_group_id, repository.name, repository.dvcs_type, repository.url, repository.branch, repository.codebase, repository.description, repository.active_status, repository.performance_alerts_enabled FROM job_detail INNER JOIN job ON (job_detail.job_id = job.id) INNER JOIN repository ON (job.repository_id = repository.id) WHERE job.guid = '3edb9a197bb1a1473bdc0d11494a986b8ece6748' ORDER BY job_detail.id DESC LIMIT 2001; When it could have just used: SELECT job_detail.job_id, job_detail.title, job_detail.value, job_detail.url, FROM job_detail WHERE job_detail.job_id = 5776 ORDER BY job_detail.id DESC LIMIT 2001;
Summary: Cleanup the /jobdetails/ endpoint and usage → Cleanup the /jobdetails/ API endpoint and usage by the UI
A lot of this weirdness is due to datasource legacy. No arguments from me that we should clean it up.
Yeah agree, not saying it's surprising it's like it is - I just wanted to file with enough details before I forgot the potential cleanup I'd spotted :-)
Assignee: nobody → emorley
Blocks: 1386331
Fixing issues 3/4 from comment 0 would have helped avoid bug 1386331.
Priority: P3 → P2
Priority: P2 → P3
Assignee: emorley → nobody
Blocks: 1504990

#1 has been addressed already in one of my PRs. But these other improvements sound great. It's an important query and improving performance here would really help.

Blocks: 1599095
Assignee: nobody → sclements
Status: NEW → ASSIGNED
Priority: P3 → P1
Type: defect → enhancement

Since it was removed in bug 1342296.

Status: ASSIGNED → RESOLVED
Closed: 4 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: