Hi Jill! You mention wanting to add a table "which stores the tree of blocks used in a course". Can you say a little more about this? I'm wondering because we've been working on a feature to visualize and query course structures in a graph-like-context by putting modulestore data into a graph database. The thing we're building is only an internal tool (not meant to be instructor facing), but I wonder if the work could overlap at all.
Adam On Friday, July 22, 2016 at 1:40:08 AM UTC-4, [email protected] wrote: > > 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] <javascript:>>: > > 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] <javascript:>>: > > 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/073300cc-87fe-46aa-8f15-11c127ba7ec0%40googlegroups.com.
