-
Bug
-
Resolution: Done
-
Major
-
DM 4.0.6
-
None
Quoting email:
The problem with long processing is there are four queries, that are compositions of four or eight subqueries and they are aggregated twice. Calculation of the unique users is not easy.
If you need to distinguish the specific distro version, app name and app version, then I suggest we add these fields to database, so it is easy for DB to filter them without the need for regular expressions. They are good in batch processing and when running in-memory operations, however applying them on the tag field would require massive communication between DB and Java. Also unless you are very fluent in regular expressions (and each language has somewhat different version of them), it would be unpleasant to use.
I suggest following:
- I will extend the API to have “user-agent” query parameter. I would expect it comes in the format you specified: "<distro-name>/<distro-version> <app-name>/<app-version>”
- distro-name would go to the current tag field unless you also pass the tag parameter (it would override the distro name)
- distro-version, app-name and app-version will get their own fields.
- I will extend the stats user interface to enable filtering by distro-version, app-name and app-version
- I also extend the REST statistic interface so you can filter by those new fields
Optional: if you want, I might try to prepare a REST datasource, that would return stats not aggregated by months or product versions, but by these four fields.
—————————————————
I suggest to do the work in the following steps steps:
1) I will update the interface for recording the user agent into database. I also convert current tag strings to the respective fields so the database is consistent. This allows you to quickly adjust the requests and the database will become filled as required.
2) I update the stats web UI to be able to filter by those fields
3) I update the stats REST API to filter by those values in case you want to use it as datasource in Klipfolio or other statistic tool, that can use external sources for data
4) Optional distro aggregated REST endpoint