[Building Sakai] Course enrollment information

Laura Gekeler LGekeler at nd.edu
Tue Sep 30 11:34:22 PDT 2014


Mark,

Thanks for taking the time and trouble to respond to me! As I said, I'm not
a developer, but I did completely understand your explanation of the
intentional strategy. And I love it. It has given me another reason to
appreciate the beauty of the inner workings of Sakai.
Now I'd like to expose it, make it as transparent as possible, cause it to
be accessible to all.... How do we do that?


Laura Gekeler
LMS Administrator //Concurrent Instructor
Apereo Foundation Board Member 2014
University of Notre Dame
P:574-631-2402


On Tue, Sep 30, 2014 at 9:36 AM, <markjnorton at earthlink.net> wrote:

> Generally, the Sakai community doesn't publish a data dictionary or an
> Entity Relationship Diagram for it's services and this is a conscious
> design choice.  Sakai developers have carefully created an API that should
> allow any software to access the data it manages and (in many cases)
> modify/create it.  This API is better documented than a DD or ERD would be
> (without a considerable amount of effort).  The published API allows
> internal changes to be made in a database representation with out affecting
> applications that use it.
>
> To expand on the example you provided, Moodle has encouraged developers to
> work directly with it's database tables, especially in the past (it is
> slowly changing, I think).  Even in Moodle 2.x, there are no established
> APIs to access Moodle data contained in database tables, though some have
> started to appear.  An ERD is useful in Moodle, because plugins and blocks
> often work directly with data in tables.  Sakai strongly discourages such
> an approach (though there are exceptions).  If you are writing tools or new
> services, you should use the Kernel APIs.  If you have external
> applications that need to access Sakai data, so it through web services or
> REST calls.
>
> - Mark Norton
>
>
> -----Original Message-----
> From: Laura Gekeler
> Sent: Sep 30, 2014 9:12 AM
> To: Neal Caidin
> Cc: sakai-dev
> Subject: Re: [Building Sakai] Course enrollment information
>
> Good Morning Neal,
>
> So, items to document and make visible in the data dictionary realm would
> be the script that enumerates tables, fields and their purposes (example
> data is really good for those of us who don't live in this realm full
> time). Another developer commented, and as a non-developer, I agree, that
> an ERD would be helpful. My basic (very) understanding of databases is
> enlivened by such visual representations. (Here's a -long- article on
> Moodle which contains an ERD:
> http://dba.stackexchange.com/questions/57524/can-anyone-please-review-my-database-after-i-did-the-normalization-any-suggest
> ).
>
> While we may already have these helpful artifacts 'somewhere', I would
> think having them in a fairly visible spot (
> https://confluence.sakaiproject.org/pages/viewpage.action?pageId=86245732
> Database Support Link?) would be most helpful.
>
> That's my 2 cents. Hope this is helpful,
>
> Laura
>
>
>
> Laura Gekeler
> LMS Administrator //Concurrent Instructor
> University of Notre Dame
> P:574-631-2402
>
>
> On Tue, Sep 23, 2014 at 9:04 AM, Neal Caidin <neal.caidin at apereo.org>
> wrote:
>
>> Hi Laura,
>>
>> It would be good to understand the needs behind the request to see if a
>> data dictionary is required to meet those needs or to understand if we all
>> have the same understanding of what a "data dictionary" is. Can you provide
>> some Use cases or examples of how a data dictionary could help you?
>>
>> And, as you well know, if you make a request, it is much more likely to
>> happen if you can contribute resources to make it happen. Do you anticipate
>> having any resources (people, money, etc) ?
>>
>> You wrote:
>> >(Maybe it already is and is one of those items which falls off every
>> time or whose format can never be agreed upon?)
>> To my knowledge there has not been any serious discussion specifically
>> about publishing a data dictionary. There has been significant energy and
>> discussion around improving Sakai technical documentation and so far we
>> have not made as much progress as I would have liked, though some technical
>> pages have been getting updated and translated to different languages
>> lately.
>>
>> Best Regards,
>> Neal
>>
>>
>> On Tue, Sep 23, 2014 at 6:42 AM, Laura Gekeler <lgekeler at nd.edu> wrote:
>>
>>> The original ask for a data dictionary would be helpful in so many ways.
>>> Could it be added as a project deliverable to an upcoming release and then
>>> its tweaking ever after? (Maybe it already is and is one of those items
>>> which falls off every time or whose format can never be agreed upon?)
>>>
>>> Laura
>>>
>>> Sent from my iPhone
>>>
>>> On Sep 23, 2014, at 3:55 AM, Steve Swinsburg <steve.swinsburg at gmail.com>
>>> wrote:
>>>
>>> Use the API's to get the data. The cm tables are used by the course
>>> management service and from you original post it doesn't look like you have
>>> a cm provider. So the users aren't going to be in those tables.
>>>
>>> If you are wanting the data in an external system there are rest and
>>> soap services to give you what you need and there are even two portlets you
>>> can use to provide a deeper integration.
>>>
>>> Cheers
>>> Steve
>>>
>>> sent from my mobile
>>> On 17/09/2014 1:45 AM, "Neal Caidin" <neal.caidin at apereo.org> wrote:
>>>
>>>> Hi Venkat,
>>>>
>>>> Thanks. I would presume you should be using the Sakai APIs. I'm copying
>>>> in the developer list so that they can provide more details.
>>>>
>>>> Cheers,
>>>> Neal
>>>>
>>>>
>>>>  <compose-unknown-contact.jpg>
>>>>  Venkat Ravikanti <vravikan at yahoo.com>
>>>>  September 16, 2014 at 10:05 AM
>>>> Neal,
>>>>
>>>> We are working on a project where we need to bring the information from
>>>> Sakai LMS and show it on external Portal for user to access.
>>>>
>>>> As you see from my original post we are not able to see the information
>>>> entered on the Sakai portal in the tables. I may be looking in wrong tables
>>>> here.
>>>>
>>>> Can you pl. guide me on this.  If you have sometime I can show you what
>>>> I am doing through Skype.
>>>>
>>>> Thanks,
>>>> Venkat
>>>>
>>>>
>>>>
>>>>
>>>>   On Tuesday, September 16, 2014 8:54 AM, Neal Caidin
>>>> <neal.caidin at apereo.org> <neal.caidin at apereo.org> wrote:
>>>>
>>>>
>>>> And of course it depends what is needed with the information. Is it
>>>> curiosity? Solving a specific problem? Writing a new tool?  Access the data
>>>> outside of Sakai? etc.
>>>>
>>>> -- Neal
>>>>
>>>>
>>>> On Thu, Sep 11, 2014 at 10:26 AM, Brian Baillargeon <bbailla2 at uwo.ca>
>>>> wrote:
>>>>
>>>>
>>>>
>>>>    <compose-unknown-contact.jpg>
>>>>  Neal Caidin <neal.caidin at apereo.org>
>>>>  September 16, 2014 at 8:53 AM
>>>> And of course it depends what is needed with the information. Is it
>>>> curiosity? Solving a specific problem? Writing a new tool?  Access the data
>>>> outside of Sakai? etc.
>>>>
>>>> -- Neal
>>>>
>>>>
>>>>
>>>>  <compose-unknown-contact.jpg>
>>>>  Brian Baillargeon <bbailla2 at uwo.ca>
>>>>  September 11, 2014 at 10:26 AM
>>>>  I just did a quick search on confluence.sakaiproject.org and found a
>>>> little documentation that hasn't been modified since 2006, but it might be
>>>> useful nonetheless:
>>>> https://confluence.sakaiproject.org/display/CM/CM+API+Design+-+Round+1
>>>>
>>>> Anyway, the table that stores roster memberships is CM_MEMBERSHIP_T
>>>>
>>>> mysql> describe cm_membership_t;
>>>>
>>>> +---------------------+--------------+------+-----+---------+----------------+
>>>> | Field               | Type         | Null | Key | Default |
>>>> Extra          |
>>>>
>>>> +---------------------+--------------+------+-----+---------+----------------+
>>>> | MEMBER_ID           | bigint(20)   | NO   | PRI | NULL    |
>>>> auto_increment |
>>>> | VERSION             | int(11)      | NO   |     | NULL
>>>> |                |
>>>> | USER_ID             | varchar(255) | NO   | MUL | NULL
>>>> |                |
>>>> | ROLE                | varchar(255) | NO   |     | NULL
>>>> |                |
>>>> | MEMBER_CONTAINER_ID | bigint(20)   | YES  | MUL | NULL
>>>> |                |
>>>> | STATUS              | varchar(255) | YES  |     | NULL
>>>> |                |
>>>>
>>>> +---------------------+--------------+------+-----+---------+----------------+
>>>>
>>>> Note: the CM_ tables store information about official rosters, which
>>>> might not necessarily map to users' current role in the site if a role has
>>>> been changed. Also, you won't find any unofficial participants in these
>>>> tables. If you want the union of official and unofficial participants, I
>>>> think they can be found in sakai_realm_rl_gr, but there might be a more
>>>> authoritative source.
>>>>
>>>> On 14-09-10 06:46 PM, Venkat Ravikanti wrote:
>>>>
>>>> _______________________________________________
>>>> 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"
>>>>  <compose-unknown-contact.jpg>
>>>>  Venkat Ravikanti <vravikan at yahoo.com>
>>>>  September 10, 2014 at 6:46 PM
>>>> Hi,
>>>>
>>>> I am new to Sakai. Need your help on the Sakai Tables.
>>>>
>>>> I am looking to find the mysql tables where the course enrollment
>>>> information stored.
>>>>
>>>> Here is my scenario:
>>>>
>>>> 1. Created Course Site with couple of courses
>>>> 2. Created Users
>>>> 3. Added the Users to the above created courses as Participants
>>>>
>>>> Now when I am trying to query for the participants information in
>>>> CM_ENROLLMENT_T or CM_ENROLLMENT_SET_T. No Luck.  These two tables are empty
>>>>
>>>> Can someone help with me following:
>>>>
>>>> 1. Data dictionary for Sakai tables with some notes on which table
>>>> stands for what
>>>> 2. Which table stores the participants or enrollment information.
>>>>
>>>>
>>>> Thanks for your help.
>>>> Venkat
>>>> _______________________________________________
>>>> 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"
>>>>
>>>>
>>>> --
>>>> Neal Caidin
>>>> Sakai Community Coordinator
>>>> Apereo Foundation
>>>> neal.caidin at apereo.org
>>>> Skype me! (but let me know in advance for the first interaction) -
>>>> nealkdin
>>>>
>>>>
>>>> _______________________________________________
>>>> 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"
>>>>
>>> _______________________________________________
>>> 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"
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20140930/fd04d4f3/attachment.html 


More information about the sakai-dev mailing list