[Design] - Support Multiple Previous Version of Question Object

Owned by Gauraw Kumar
Last updated: Mar 17, 2022
3 min read

Problem Statement:

  • Platform should maintain and support multiple version of the question object. So that any questionset created with previous version of the question won’t break in case of online consumption.

Current Behaviour:

abstract getQuestions(identifiers: string[], parentId?: string): Observable<Question>; abstract getQuestion(identifier: string): Observable<Question>;

  • The Question List API, takes list of identifiers and returns complete data (graph data + external data) for all identifiers.

  • Request Structure of Question List API is as below:

curl 'https://staging.sunbirded.org/api/question/v1/list' \ -H 'Content-Type: application/json' \ --data-raw '{ "request": { "search": { "identifier": [ "do_21348431719053721619", "do_213484318131216384111" ] } } }'

Solution: Using Cloud Store

Data Creation:

  • On Successful publish, create a json having complete data of the object which includes graph & external data for current version of the object. (e.g: data_pkgVersion.json)

  • e.g: The data file will be stored from current publish version.

  • The json created above will be stored in cloud storage. Path for data will be as below:

  • /objectType/identifier/data_version-number.json e.g: /question/do_1234/data_1.json /question/do_1234/data_2.json

  • Few fields which are not required for consumption like editorState will be removed from data.json. Removal of fields will be controlled through object schema config removeArchieveFields

  • The number of previous version supported by platform will be controlled through a schema config previousObjectVersion

  • default value for above config will be 5. This number can vary from one objectType to another.

  • once number of records for an object will reach the number set in previousObjectVersion, then the lowest version gets deleted when new version gets published (FIFO)

Data Consumption:

  • The Question List API will be enhanced to take list of objects. The API Request Structure will be as below:

  • Backward compatibility of above api will be maintained.

  • If the identifiers are provided along with version, first all nodes will be fetched from graph and pkgVersion will be compared with request version.

  • If Requested version is less than the current version, data for that particular node will be fetched from cloud and merged with result.

  • For Node matching latest version, external data will be fetched from cassandra database.

  • If data not found over cloud for some of requested object, the question list api will have below response:

    • if query parameter fallback=latest is supplied in the request, platform provides the latest version data. In this case, if the actual question is changed with latest version, the user experience may get affected but won’t affect score computation.

    • if query parameter fallback=latest is not supplied in the request, platform will throw an error (400 or 404). In this case, the questionset consumption will break down but won’t compute wrong score.

  • The Question Read API will also be enhanced to support version .

    • The Read api will accept a query parameter version=pkgVersion to fetch specific version data. e.g: question/v1/read/do_123?version=1&fields=body&fallback=latest

    • if the data is not found for version requested, read api will also have same behaviour as in question list api.

  • A service level config question.version_enable will be used to control the version feature. By default, it will be set to true.

Code Changes Required:

  • questionset publish backend job need to be enhanced for writing version specific data.

  • question list api need to be enhanced for reading specific version data.

  • question read api will be enhanced to support specific version data.

  • All Player Implementation ( Web Portal, Mobile App, Offline Desktop App) need to change the question list api request. However it is not mandatory on immediate basis as question list api supports backward compatibility.

 

Editor Behaviour:

  • if user is editing a published version of questionset, editor will make a hierarchy read api call with mode=edit.

  • hierarchy read api with mode=edit always returns latest version of children. So the changes in children question will be visible in preview at the time of modification and review. So no changes need to be done at editor end.