[Building Sakai] Discussion: KNL-364 and KNL-500

Jean-Francois Leveque jean-francois.leveque at upmc.fr
Fri May 21 07:58:48 PDT 2010


-1 on adding USER_ID to SAKAI_EVENT, not a good idea from a DB point of 
view : denormalization

Why not caching?

cheers,
Jean-Francois

Dunstall, Christopher a écrit :
> Definitely a +1 for this.  
> 
> This would make statistics generation faster and less resource hungry than it currently is.
> 
> 
> Chris Dunstall | Service Support - Applications
> Technology Integration/OLE Virtual Team
> Division of Information Technology | Charles Sturt University | Bathurst, NSW
> 
> Ph: 02 63384818 | Fax: 02 63384181
> 
> 
> -----Original Message-----
> From: sakai-dev-bounces at collab.sakaiproject.org [mailto:sakai-dev-bounces at collab.sakaiproject.org] On Behalf Of Steve Swinsburg
> Sent: Wednesday, 19 May 2010 10:26 PM
> To: sakai-dev at collab.sakaiproject.org Developers
> Subject: [Building Sakai] Discussion: KNL-364 and KNL-500
> 
> Some recent work in the UsageSessionService and EventTrackingService API's has brought to the surface this old feature request, adding a USER_ID field to the SAKAI_EVENT table. http://jira.sakaiproject.org/browse/KNL-364
> 
> As it stands, to get the userId of the person who published an event, you must go via the sessionId. This is achieved via: UsageSessionService.getSession(id) however this is a database query, and there is no cache so is a potential bottleneck.
> 
> Interestingly, Event.getUserId() has a comment in its Javadoc that if the value is null, to use the session. However, this value is always null, it's never set.
> 
> And while we are at it, might as well add a getter to the Event object for the time field, since there is no way to get that either, even though it is stored in the table.
> http://jira.sakaiproject.org/browse/KNL-500
> 
> Thoughts?
> 
> cheers,
> Steve


More information about the sakai-dev mailing list