Danius Michaelides wrote:
[snip]
I guess some of this will change with Sergey's news code.
Sergey's news code just affects the "my news" box on the home page
(and other user and group show pages) and will be the mechanism for
subscriptions that require events spanning *different* models. It
won't be used for the other boxes on the home page, as those are
events pivoted on one model and using the ActivityLog stuff would
mean having to at least one extra query, with extra logic, and also
require it's own caching.
Hang on, ignoring caching for the minute, are you saying that Sergey's
ActvityLog stuff wont be driving updated items? If so, I dont understand
your explaination, can you or Sergey go into more detail?
Sure.... the ActivityLog stuff stores events in the following general
pattern - <culprit> did <action> <ActivityLoggable> affecting
<referenced>. E.g: (User 201) did (add) (PackContributableEntry 500)
affecting (Pack 20). Note: this is NOT the wording in the news feed,
just the pattern of how events are stored in the model/db. For some
events, the <referenced> is not needed.
When it comes to news generation (for disparate events), you start by
querying the ActivityLog table (Sergey: please can you briefly
elaborate on the different types of root queries needed on
ActivityLog, for the different types of news feeds) and then other
tables need to be queried to get back the relevant items (and to see
if they exist), and then authorisation needs to take place.
So, going back to the "Updated Items" box... this is pivoted on one
model - Contribution. So it gets the last 15 contributions added to
the contributions table and then builds the view by getting the
contributable. Policy and Permissions are eager loaded with the
Contributions so authorisation can take place without going back to
the db. Using ActivityLog for this won't help as You would first need
to get the events from the ActivityLog and then get the contributable
items and authorisation stuff anyways.
We could have stored a bit of text like: "John added the Blast
Workflow to the TestWorkflows pack" but this suffers from two issues:
1) it's not easily queryable so it's hard to reuse the activity log
for different kinds of news feeds and also for different kinds of
subscriptions.
2) authorisation information needs to be retrieved from somewhere.
Does this help?
Jits
Danius
_______________________________________________
myexperiment-hackers mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/myexperiment-hackers
_______________________________________________
myexperiment-hackers mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/myexperiment-hackers