259
edits
Webdev:Meetings:2009-09-01: Difference between revisions
→Open Items
(paging option) |
|||
| (4 intermediate revisions by 4 users not shown) | |||
| Line 8: | Line 8: | ||
** Write something way lighter weight to build CSVs on the fly. We can't scale this way forever though. | ** Write something way lighter weight to build CSVs on the fly. We can't scale this way forever though. | ||
** Limit the number of rows returned but provide paging params to view older ranges of data | ** Limit the number of rows returned but provide paging params to view older ranges of data | ||
*** +1 --[[User:Wenzel|wenzel]] | |||
** Output CSV as it is generated and bypass Cake views, thus avoiding the need to generate huge arrays of data | |||
** Each add-on id gets its own tables stats.addonid.* and some data is only offered for a year: | |||
*** *.downloads: date, version, n° of downloads | |||
*** *.usage_total: date; sum of update pings | |||
*** *.usage_apps: date, app, update pings | |||
*** *.usage_ly_versions: date, version, update pings (only for last year) | |||
*** *.usage_ly_apps_and versions: date, version, app, appversion, update pings, userEnabked pings, incompatible pings (only for last year, is there a need for needsDependencies or blocklisted?) | |||
*** *.usage_ly_os: date, app, os, update pings (only for last year) | |||
** Maybe a service to mail the developer the csv data once per week/month | |||
** Can metrics do this for us? | |||
** Why get all the data in memory at once? We could have a little service that builds the csv and streams it out to disk. Let that stay cached for however long is appropriate. | |||
** '''add more ideas! thx''' | ** '''add more ideas! thx''' | ||