resty tracking issue - Githubissues

SamStudio8 / majora2

Malleable All-seeing Journal Of Research Artifacts

MIT License

36 stars 7 forks source link

resty tracking issue #26

Open SamStudio8 opened 4 years ago

SamStudio8 commented 4 years ago

[ ] update v3 to use new institute credits - eventually migrate default credit to same system
[x] check the actual mdv permission as well as the permission key
[x] check the new permissions model works on list as well as retrieve (cant we just override get?)
[x] add permissions to tatlauthenticator
[x] add accesses and time taken metrics to dataview, return average wait time to client
[x] basic example
[x] intergrate with celery

SamStudio8 commented 4 years ago

add accesses and time taken metrics to dataview, return average wait time to client

this is done by the tatltask now

SamStudio8 commented 3 years ago

The v3 API is a great success in that its quite a technical achievement. Sadly the performance is garbage, as DRF exacerbates the n+1 query problem. This isn't a fault of DRF, just the implementation is in contradiction to the highly interconnected artifacts and processes in Majora, which adds a significant query overhead. No doubt this could be improved somewhat with careful use of prefetching in the right places but I think we won't be able to move forward with v3 without a sensible cache in front of the groups (if not the artifacts too).