Re: [myexperiment-hackers] Problem with /home caching

[Sergejs Aleksejevs]

Hello,

A little correction: different fields of ActivityLog table may not be 
required for different events. For example, when a user updates their 
account settings only "activity_loggable" is set to the user's account 
(not the profile!), other fields would be redundant: the ActivityLog 
record is <culprit==NULL> did <create|update|destroy> <User 432> 
affecting <referenced==NULL>.

There are different types of news feed -
* what the user sees on their home page / profile page
* what other users see on the user's profile page
* news for the group

I'll try to give an idea of how the news feeds are generated (in this 
case, for the user's home page):
1) First the ActivityLog table is queried to get all events, having 
current user as Culprit, ActivityLoggable or Referenced. This gives a 
set of events, relevant only to the current user (without their friends, 
etc). Not all the events in this set are supposed to be displayed in the 
news - for example, we drop all the "destroy" events, or some "updates" 
and "creates" may have the same meaning in the context of news.

2) A collection of "related contributors" is generated from all user's 
friends and members of the groups, where the current user is admin or 
member of (to be confirmed that we want this). Events from ActivityLog 
are fetched for each of the "related contributors" recursively.

3) All set of events is processed to generate the actual news feed (to 
which viewing permissions will be applied), checking that the events are 
still valid (e.g. if the workflow was created and then deleted, there's 
no need to display that it was created in the first place).

(We're going to optimize the queries by using eager loading and any 
other possibilities for that.)

Let me know, if I should provide more details.

Sergey


Jiten Bhagat wrote:
> 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