Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consolidate rating mechanism #9

Open
jcfr opened this issue Feb 14, 2012 · 3 comments
Open

Consolidate rating mechanism #9

jcfr opened this issue Feb 14, 2012 · 3 comments
Assignees
Labels

Comments

@jcfr
Copy link
Contributor

jcfr commented Feb 14, 2012

The API associated with the rating module should allow to compute the average score on a list of items.

@ghost ghost assigned zachmullen Feb 14, 2012
@zachmullen
Copy link
Member

Ratings and comments can both be consolidated using a proxy item. This proxy item will be referenced by each instance of the extension that is uploaded, but ratings applied to the instance will actually be applied to the proxy item for aggregation. These items will be hidden from normal users and will allow for fast reads and writes of ratings and comments. It also allows for flexibility of how to define a distinct conceptual set of things that should be grouped together for the purpose of rating and commenting.

@jcfr jcfr assigned mwoehlke-kitware and unassigned zachmullen Mar 28, 2014
@jcfr
Copy link
Contributor Author

jcfr commented Mar 28, 2014

@mwoehlke-kitware:

  • This is low priority
  • Check with @zachmullen if you have any question.

@zachmullen Is the proposed approach still the recommended way of solving this ?

@mwoehlke-kitware
Copy link
Contributor

It seems like this sort of thing (also aggregated download statistics) ought to be done by changing the database schema to keep track of non-versioned extension information. Writing back changes is probably not difficult (just twiddle what table is written to). Reading can be done with a join query.

The "proxy item" sounds suspiciously like this already...

The main hiccup is that this is a schema change, and the main server would have to be taken offline long enough to build the table with the aggregated data (and probably to run a cold backup first). Once it's done though it would be much easier to simply drop old builds from the database without affecting the aggregate data.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Development

No branches or pull requests

3 participants