[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