Hi Jill et al, Thanks for starting this thread. (I had been away on vacation and am catching up.)
For the mobile app, we've been considering using ETags to eliminate extra work in updating its local cache. However, the use case there is a bit more complicated since we need to check for user-access state-changes in addition to course-state changes. For your use case, however, since you only care about course-state changes, it is very plausible *now* for us to build what's required with minimal effort. With the following recent PR, we were able to update the SplitModulestore and enable a BlockTransformer to store the course_version (guid) and subtree_edited_on (timestamp) fields with the cached course structure: https://github.com/edx/edx-platform/pull/13082 So now, this data is available to the Course Blocks API. The subtree_edited_on timestamp may be all that you need to embed in the ETag when non-user-specific blocks are requested (i.e., when all_blocks=true URL param is specified). Nimisha On Fri, Jul 22, 2016 at 10:14 AM, Adam Palay <a...@edx.org> wrote: > 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, ji...@opencraft.com 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@5 >> 19665f6223ebd6980884f2b >> >> *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 <bra...@opencraft.com>: >> >> 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+bran >>> ch@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 <ga...@edx.org>: >> >> 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/CACSOLjdJxTYRU1sRBxcOSAVahFV1NHfYdTbrBMn80Y7MhX6Y_A%40mail.gmail.com.
