software-store-developers team mailing list archive

[Aaron Peachey <alpeachey@xxxxxxxxx>]

Hi again all,

I've been thinking about plans for implementing this and think there
are some decisions to make first...

If I understand the spec correctly in that we need to know how many
ratings have been made for each app at each step of 1,2,3,4 and 5,
this information isn't currently returned to us by the server
(review_stats() gives us appname, package name, ratings total and
rating average).

We need to make changes to the server for this, and my thoughts about
how we approach this have come up with a few options.

Option 1: maintain a field against each app on the server with the
current ELR number. This would mean every time someone submits,
modifies, deletes or hides a rating for that app, the server would
need to re-calc the ELR at the time.
The benefit of this is we can simply return the ELR to the client
whenever the client asks for ratings. Because we often ask for alot of
these in one hit (e.g. updates last X days) this would be a benefit
performance wise where it counts.
However, it would come at the cost of some time for every action that
affects ratings for the app, because we need to re-calc every time.

Option 2: maintain 5 fields against each app on the server, with the
total ratings for each step. This would be a much simpler calculation
at the time of submit/delete/modify/hide but a performance hit upon
retrieval of ratings in a bulk fashion because somewhere we need to do
the ELR calc for every app that has changes in ratings
This could either be done by calculating the ELR on the server before
returning it or just returning the 5 integers* and having the client
work out the ELR.

Option 3: Don't maintain any additional fields for this purpose on the
server, but when asked for ratings, the server then needs to trawl
through the DB to count the number of ratings at each step, before
then returning either (a) the 5 integers or (b) the calculated ELR.
This would be the worst performance hit at the time of retrieving
ratings and is probably not viable.

*We need to keep in mind, that if we go down the path of showing a
distribution of ratings for each package, then we will probably need
the 5 integers to be returned to the client in order to work out the
distribution. With this in mind, I'd suggest we need to go with option
2 and have the server return the 5 integers to the client, who then
uses them to calculate the ELR and work out the distribution of
ratings for display.

Thoughts? Other options?

cheers
Aaron