In my checkout of HEAD, at least, ratings/sql/oracle is empty.
Ooops! Looking at what's inside the sql/oracle would have been a good idea... or cvs co -Pd :)
The "context_object_id" column is not fill automatically with the context_id of the object but with whatever is passed as context_object_id by the page that uses ratings. So if you use the ratings proc (should be an include btw), say, in forums package in the page that display 1 thread, you can pass the forum_id as context_object_id.
The aggregating stuff in Jeff's original code aggregates ratings by type of users (registered, anonymous, all), if I understood correctly the identifiers:
create table rating_aggregates (
dimension_id integer
constraint ratings_dimension_id_fk
references rating_dimensions(dimension_id) on delete cascade,
object_id integer
constraint ratings_object_id_fk
references acs_objects(object_id) on delete cascade
constraint ratings_object_id_nn
not null,
all_ratings integer,
all_rating_sum integer,
all_rating_ave float,
anon_ratings integer,
anon_rating_sum integer,
anon_rating_ave float,
reg_ratings integer,
reg_rating_sum integer,
reg_rating_ave float,
rated_on timestamptz,
constraint rating_aggregates_pk
primary key (object_id, dimension_id)
);
Regarding other Viaro's changes: the duplication of code can be cleaned up and I forgot to mention that they added scripts to view a summary (or details) of the ratings (by object, by user who rated), that can be interesting. The question is if those summaries should be restricted to users with admin privilege or not.
