[Building Sakai] adding user event tracking to sitestats

[Paul Lukasewych]

Thanks Steve.

We run an external db for sitestats so I'm thinking option 2 would lessen the 
load on the primary db and maybe perform better for reads in our case.

Option 1 is also complicated by the fact that we archive our event and session 
tables after a period of time. Instructors often want to look for events that 
occurred days or even weeks in the past so then we'd have to go looking in 
archive tables as well. However, given enough time running option 2 we'd 
probably have to archive the events there as well.

Paul Lukasewych
Applications Development Team
Information Technology Services
Support Services Building
Western University
(519) 661-2111 x80513
plukasew at uwo.ca

On May 9, 2014 00:45:14 Steve Swinsburg wrote:
> Hi Paul,
> 
> Option 1 would be ok if you were able to limit the date ranges and or
> provide some sort of aggregation for data older than say 24 hours. It's
> three joins and shouldn't be a lot of work for the database to manage. I
> know its slow on these particular tables, perhaps a materialised view would
> be good to have here.
> 
> Option 2 I am wary of because it would need to intercept almost every event
> and do something with it in code. It does do a lot of this now, so the
> performance tradeoff may be minimal. At least you could leverage the event
> aggregation, though for reading the data you wouldn't be any better off
> than having a view as in 1.
> 
> cheers,
> Steve
> 
> On Fri, May 9, 2014 at 12:11 AM, Paul Lukasewych <plukasew at uwo.ca> wrote:
> > We would like to add the ability to retrieve the actual event information
> > (not
> > just an aggregate count) for a particular user from the sitestats tool.
> > Our
> > user community is used to having this information available, as it was a
> > standard feature of our previous LMS (WebCT) and was quite heavily used.
> > 
> > >From what I can tell, this could be done in a couple of ways:
> > 1. On-demand querying of the sakai_event/sakai_session tables (maybe there
> > is
> > an API call for this instead?) when a user wants to see the event details
> > 
> > 2. Add an extra table to sitestats to store the extended information
> > rather
> > than just the count
> > 
> > >From my experience querying the database directly, option 1 is going to
> > >be
> > 
> > extremely slow, whereas option 2 is essentially duplicating a lot of
> > information that already exists elsewhere
> > 
> > If anyone has done something like this before, or has any
> > thoughts/opinions
> > about the best approach, I'd be interested in hearing it.
> > 
> > Thanks,
> > 
> > Paul Lukasewych
> > Applications Development Team
> > Information Technology Services
> > Support Services Building
> > Western University
> > (519) 661-2111 x80513
> > plukasew at uwo.ca
> > _______________________________________________
> > sakai-dev mailing list
> > sakai-dev at collab.sakaiproject.org
> > http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
> > 
> > TO UNSUBSCRIBE: send email to
> > sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
> > "unsubscribe"