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

Dunstall, Christopher cdunstall at csu.edu.au
Wed May 19 17:40:27 PDT 2010


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
_______________________________________________
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"


More information about the sakai-dev mailing list