Uploaded image for project: 'Sakai'
  1. Sakai
  2. SAK-10801

Add contextId (siteId) field to Event

    Details

    • Type: Task
    • Status: Closed
    • Priority: Major
    • Resolution: Fixed
    • Affects Version/s: 1.0, 1.5.0, 1.5.1, 2.0, 2.0.1, 2.1.0, 2.1.1, 2.1.2, 2.1.x, 2.2.0, 2.2.1, 2.2.2, 2.2.3, 2.2.x, 2.3.0, 2.3.1, 2.3.x, 2.4.0, 2.4.1, 2.4.x, 2.5.0, 2.5.2, trunk
    • Fix Version/s: 2.6.0
    • Labels:
      None
    • Environment:
      Any

      Description

      Currently, there is no efficient and deterministic way to know in which context (siteId) an event was generated. The current work-around for this is to parse the Ref field and try to guess the context.

      Events can be sakai scoped (with new contextId field set to null) or site scoped (contextId set to siteId). This would probably involve adding a column to SAKAI_EVENT and a setter a getter for it in the Event class.

        Gliffy Diagrams

          Attachments

            Issue Links

              Activity

              Hide
              lance@indiana.edu Lance Speelmon added a comment -

              IU needs this implemented by August 16th, 2007 for a production roll out of Site Stats. Andrew will work with Glenn to make it happen. Thanks, L

              Show
              lance@indiana.edu Lance Speelmon added a comment - IU needs this implemented by August 16th, 2007 for a production roll out of Site Stats. Andrew will work with Glenn to make it happen. Thanks, L
              Hide
              ajpoland Andrew Poland added a comment -

              Here's a first attempt that is based on the reference parsing functions that Nuno wrote into sitestats.

              Certainly we want to provide a cleaner implementation for 2.5, however Oncourse will be using this to get things rolling for our release next week.

              This patch will populate a new column in SAKAI_EVENT called CONTEXT:

              alter table sakai_event add CONTEXT VARCHAR2(99);

              Andrew

              Show
              ajpoland Andrew Poland added a comment - Here's a first attempt that is based on the reference parsing functions that Nuno wrote into sitestats. Certainly we want to provide a cleaner implementation for 2.5, however Oncourse will be using this to get things rolling for our release next week. This patch will populate a new column in SAKAI_EVENT called CONTEXT: alter table sakai_event add CONTEXT VARCHAR2(99); Andrew
              Hide
              nfernandes Nuno Fernandes added a comment -

              Please note that the process of filling the new CONTEXT column for existing data in SAKAI_EVENT will not be perfect:

              Both EVENT and REF field contents have changed for the same event across Sakai upgrades!

              As an example, Message Center have changed their events from content.* to msgcntr.* (content.* are associated with the Resources tool so, were ambiguous) and their references changed the path separator from : to / (more consistent with the remaining events).

              Show
              nfernandes Nuno Fernandes added a comment - Please note that the process of filling the new CONTEXT column for existing data in SAKAI_EVENT will not be perfect: Both EVENT and REF field contents have changed for the same event across Sakai upgrades! As an example, Message Center have changed their events from content.* to msgcntr.* (content.* are associated with the Resources tool so, were ambiguous) and their references changed the path separator from : to / (more consistent with the remaining events).
              Hide
              smarquard Stephen Marquard added a comment -

              Creating a branch to try out an implementation of this

              Show
              smarquard Stephen Marquard added a comment - Creating a branch to try out an implementation of this
              Hide
              smarquard Stephen Marquard added a comment -

              Patch for search (mock service)

              Show
              smarquard Stephen Marquard added a comment - Patch for search (mock service)
              Hide
              smarquard Stephen Marquard added a comment -

              Resolved in trunk: r47466:47469 (event, search, memory, reference)

              Show
              smarquard Stephen Marquard added a comment - Resolved in trunk: r47466:47469 (event, search, memory, reference)
              Hide
              smarquard Stephen Marquard added a comment -

              And 47471,47472 (entitybroker, content)

              Show
              smarquard Stephen Marquard added a comment - And 47471,47472 (entitybroker, content)
              Hide
              mmmay Megan May added a comment -

              removing the 2.5.x merge status as branch managers discussion determined this a fairly substantial change in functionality and thus, didn't meet the criteria for 2.5.x

              Show
              mmmay Megan May added a comment - removing the 2.5.x merge status as branch managers discussion determined this a fairly substantial change in functionality and thus, didn't meet the criteria for 2.5.x
              Hide
              smarquard Stephen Marquard added a comment -

              From sakai-dev:

              >>> "Stephen Marquard" <stephen.marquard@uct.ac.za> 9/2/2009 8:42 PM >>>
              There are 3 ways in which the CONTEXT can be set:

              1. The entity code for the event reference has a parser which will return the context for the reference concerned, e.g. in references like /content/group/53450fdc-643a-4bf9-a860-adca9c72bbaf/, the context is embedded in the reference.

              2. If the reference itself doesn't yield a context from the reference's service, then the tool context in which the request thread is executing is used as the context. This means that events posted by a tool placed in a site in response to a user action will get the context of that site.

              3. A tool or service may explicitly pass the context when it posts events using an extra parameter.

              In some of your examples:

              Creating a new site - you do so from your My Workspace, so the context is your workspace's site id, except for some events where the context is derived from the ref.

              alias.add events may come from new site creation, or may come from the site itself (e.g. adding Email Archive in Site Info vs configuring it in My Workspace when creating a site).

              As you've noted, the CONTEXT is not completely consistent but it is a progressive improvement on 2-5-x as it allows many more events to be reliably associated with sites (viz. for those tools which use event REFs that don't include a site id).

              Feel free to add JIRAs for cases that you think are truly inconsistent. It's possible some of those inconsistencies could be straightened out by getting the tools/services to explicitly set the context to whatever is most appropriate.

              Cheers
              Stephen

              >>> Steve Lonn <slonn@umich.edu> 9/2/2009 8:20 PM >>>
              Please forgive a very non-technical question...

              I am just beginning to get familiar with the way Sakai 2.6 logs
              events, particularly with regard to a new column in the table "context"
              It appears that the goal of this field is to grab the site_id that is
              associated with this event, which is very helpful.
              However, it appears that sometimes this field is not grabbing the
              site_id at all, resulting in a (null). Othertimes, it seems to grab
              the user's ID or the ID of their My Workspace instead of the site they
              are using.

              If someone can please explain what's going on, where the known gaps
              are, etc. I would greatly appreciate it, particularly since this
              information does not appear to be captured in the relevant JIRA
              entries (SAK-10801, SAK-13809)

              Thanks! Steve

              Show
              smarquard Stephen Marquard added a comment - From sakai-dev: >>> "Stephen Marquard" <stephen.marquard@uct.ac.za> 9/2/2009 8:42 PM >>> There are 3 ways in which the CONTEXT can be set: 1. The entity code for the event reference has a parser which will return the context for the reference concerned, e.g. in references like /content/group/53450fdc-643a-4bf9-a860-adca9c72bbaf/, the context is embedded in the reference. 2. If the reference itself doesn't yield a context from the reference's service, then the tool context in which the request thread is executing is used as the context. This means that events posted by a tool placed in a site in response to a user action will get the context of that site. 3. A tool or service may explicitly pass the context when it posts events using an extra parameter. In some of your examples: Creating a new site - you do so from your My Workspace, so the context is your workspace's site id, except for some events where the context is derived from the ref. alias.add events may come from new site creation, or may come from the site itself (e.g. adding Email Archive in Site Info vs configuring it in My Workspace when creating a site). As you've noted, the CONTEXT is not completely consistent but it is a progressive improvement on 2-5-x as it allows many more events to be reliably associated with sites (viz. for those tools which use event REFs that don't include a site id). Feel free to add JIRAs for cases that you think are truly inconsistent. It's possible some of those inconsistencies could be straightened out by getting the tools/services to explicitly set the context to whatever is most appropriate. Cheers Stephen >>> Steve Lonn <slonn@umich.edu> 9/2/2009 8:20 PM >>> Please forgive a very non-technical question... I am just beginning to get familiar with the way Sakai 2.6 logs events, particularly with regard to a new column in the table "context" It appears that the goal of this field is to grab the site_id that is associated with this event, which is very helpful. However, it appears that sometimes this field is not grabbing the site_id at all, resulting in a (null). Othertimes, it seems to grab the user's ID or the ID of their My Workspace instead of the site they are using. If someone can please explain what's going on, where the known gaps are, etc. I would greatly appreciate it, particularly since this information does not appear to be captured in the relevant JIRA entries ( SAK-10801 , SAK-13809 ) Thanks! Steve
              Hide
              nfernandes Nuno Fernandes added a comment -

              Issue verified (should have been closed earlier).

              Show
              nfernandes Nuno Fernandes added a comment - Issue verified (should have been closed earlier).

                People

                • Assignee:
                  smarquard Stephen Marquard
                  Reporter:
                  nfernandes Nuno Fernandes
                • Votes:
                  4 Vote for this issue
                  Watchers:
                  4 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved:

                    Git Source Code