Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Validate QuizSectionSerializer.resource_pool against actually-used information #11798

Closed
3 tasks
nucleogenesis opened this issue Jan 25, 2024 · 2 comments
Closed
3 tasks

Comments

@nucleogenesis
Copy link
Member

Overview

We fetch a whole tree of data which includes a lot of data that we don't use and will not use for the purposes of QuizCreation.

This results in a lot of extra data ending up in the database.

Currently, it is using a HexUUIDField as the child validator. It doesn't seem like saving the IDs only will be helpful as we need things like the ancestors and assessmentids to be included there, likely including a few other things.

Acceptance criteria

  • Bring parity between the QuizExercise type defined in quizCreationSpecs.js and the actual results we're saving in the resource_pool that are fetched by way of ContentNode.fetchTree - basically, update the fields to match the names in the API response, then only keep the ones that are being used during QuizCreation
  • During useQuizCreation#addToWorkingResourcePool (merged in Synchronise user selections with Quiz Creation State  #11783) massage the fetchTree-fetched data to map to the newly updated QuizExercise typedef
  • There needs to be a better validator on the QuizSectionSerializer.resource_pool which ensures that only the required fields are listed there - basically, make a Django serializer which matches the newly updated QuizExercise type.
@rtibbles
Copy link
Member

I am a bit confused by the requirements here - listing anything more than the ids for the ContentNodes will mean that we are creating an implicit cache of the content node metadata, with no real mechanism for invalidating it. Surely the point of only storing the ids is so that we can fetch the most up to date metadata from the content node API?

@nucleogenesis
Copy link
Member Author

Thanks @rtibbles -- I'll close this and update #11783 to pass the IDs only to the API

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants