Wednesday, September 13, 2006


Enterprise id is killing me

Will there be no end to the confusion of the Id vs. the Eid? I need more than two hands to count the number of ways this has tripped me up. In the old days, Sakai only used one id. As of Sakai 2.2.0, there's Sakai's internal id, and the institution's id, or enterprise id (eid). Some parts of Sakai's API want an id, other parts want an eid. Usually anything that interacts with your providers (i.e., your enterprise) should get an eid. This seems perfectly reasonable, but it's not as cut and dried as it seems. For instance, CourseManagementService.getInstructorCourses(instructorId) seems like it would take an eid, because you're going to get your courses from your student information system, which only knows about the enterprise id. It turns out though, that CourseManagementService expects a Sakai id, and then does an eid lookup inside the getInstructorCourses method before delegating to the CourseManagementProvider to get the info out. You don't always know right away when you have a problem in this regard, because many users have a Sakai id that is equal to their eid (this turns out to be any user who was in your database at the time you did the conversion to 2.2.0). For these users, all the code that takes any kind of id still works even if you're sending the wrong id. Then gradually your system fills up with new users with a Sakai-generated guid and then things really get “interesting.” Your brain really starts to hurt when you try to make the right list of participants show up in the Site Info tool, because any participants who came to your course from the CourseManagementProvider are represented by an object of type CourseMember and any participants who were manually added by site maintainers are represented by an object of type Participant. The CourseMember has an Id field and Uniqname field. The Participant has an Eid field, a Uniqname field, and a DisplayId field. So what is Uniqname? Is it an Id? Is it an Eid? Turns out it's an Id, and woe betide you if you stuff an Eid in there. So now you can be either a participant or a course member, and you can either have a guid for an id or an eid for an id, and every combination can produce different results. I'm not even going to touch DisplayId. This is all just a long-winded way of saying the dreaded Eid hit me twice again today. I have a homegrown tool for staff to use to associate rosters with instructors. It broke because it was passing an eid to the CourseManagementService. Also, I had to ask for a bug I reported, SAK-6222, to be retracted because I thought SiteAction was misusing the CourseManagementService when it really wasn't.

It took me several minutes to realize what you were talking about. I kept thinking, "But Ramadan does even start until the 24th. Eid's not for another month yet."
That occurred to me momentarily while I was writing. I should be more careful with my acronyms!
i know what you mean about the id & eid. i think it part of a large picture of descriptive var name. i'm sure you browse the .vm files with var name such as u = bah, or rv = blee, etc. maybe in 3 years it will be much much better.
Post a Comment

<< Home

This page is powered by Blogger. Isn't yours?