Hi, This post is partly to record discussions going on in a planning document, and partly to spark more discussion on the topic.
Nimisha, do you have a list of pending API improvements where this feature request could be captured? *Feature Idea* Update the Courses API <http://edx.readthedocs.io/projects/edx-platform-api/en/latest/courses/courses.html#get-details-for-a-course> to add the current published version ID, which is available from the modulestore. Example: course-v1:mit.eecs+6002x+branch@published+version@519665f6223ebd6980884f2b *Impetus* We're working on adding a table to the analytics data which stores the tree of blocks used in a course, as retrieved from the Course Blocks API <http://edx.readthedocs.io/projects/edx-platform-api/en/latest/courses/blocks.html> . Since this table may be relatively expensive to maintain, we'd like to be able to update it only when a course has changed, i.e. when a course or any of its sections is Published. If we knew the current published version ID, then we could update the table only if the current published version has changed. *Discussions*: Captured for posterity. >From Braden MacDonald <[email protected]>: Every course in split modulestore has a version (internally), and any > change to the structure of the course (or any content, too, I suppose) will > change the version (which is just a mongoDB ObjectId). So "all you need to > do" is store the result of the Course Blocks API query for each course > along with the "version of the published branch" of that course. Then, you > only need to re-fetch the block structure if the current version doesn't > match the cached result version. > A course's ID string/key can actually include this version information, > though this form is rarely seen: > "course-v1:mit.eecs+6002x+branch@published+version@519665f6223ebd6980884f2b" > > From what I recall about split's "versions" table, a MongoDB query to > fetch a list of all courses and the version of each would be trivial and > fast, though I don't know if there is currently any API which exposes it. > FWIW I implemented content libraries using that approach - the randomized > content block checks the version of the library to know when to prompt the > course author to update. If we used that approach it should be non through > some API that's not directly related to the modulestore. >From Gabe Mulley <[email protected]>: Yeah, I thought about leveraging that data. I'm not aware of any API that > exposes it, however, and am very wary of reaching in behind the modulestore > API (given how complex it is). > I like the idea of using the version, though, to determine which courses > need to be pulled again instead of time. Maybe we could leverage entity > tags? Basically set the etag to the version identifier? Maybe it already > does this? > I'm not very familiar with conditional get semantics, but I think we could > then use "If-None-Match" to short-circuit and return a 304 if the course > hasn't changed. Thank you! -- Jill @OpenCraft <http://opencraft.com/> -- You received this message because you are subscribed to the Google Groups "General Open edX discussion" group. To view this discussion on the web visit https://groups.google.com/d/msgid/edx-code/cedb8238-e452-467d-ab25-544c73e8a359%40googlegroups.com.
