Note that more discussion about this has been happening on this ticket: https://openedx.atlassian.net/browse/TNL-4891
Thanks, -Gabe On Fri, Jul 22, 2016 at 1:40 AM, <[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]>: > > 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 > <https://groups.google.com/d/msgid/edx-code/cedb8238-e452-467d-ab25-544c73e8a359%40googlegroups.com?utm_medium=email&utm_source=footer> > . > -- 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/CAN%3Dj4kH9C_fBL_JjdiiWdqMx%3DbbdjORsyv4K%3DOAvDGaPagxDZA%40mail.gmail.com.
