Referenced from Dave's comment on the parent ticket:
Making a staged restore LearningPackage
The key field needs to be unique across LearningPackages, and the orgs might not match up to anything we have on a new instance. So we're going to encode information from the original archive into it like this:
Example: lib-restore:dave:Axim:problem-bank:1002
In this case, the original archive was lib:Axim:problem-bank. When we generate the LearningPackage, we encode that it's a special "restore" learning package (lib-restore) that dave has just uploaded. The 1002 can just be pulled from the LearningPackage's primary key--we only need it to ensure uniqueness.
Edit: Since we probably want to pass in the key when creating the learning package, it can't be the primary key. We could instead create a short random value and hex-encode it.
Where does the Archive metadata being reported actually live?
The UserTask that we create for the upload process will make at least two artifacts:
- the error log text file will keep error messages and only be shown to the user when things go wrong.
- the summary JSON file will hold all the metadata that is shown in the box above, along with the real LearningPackage.key of the generated LearningPackage.
Doing the actual Library Creation
We add a new optional arg to the library creation endpoint to take the key of the LearningPackage that we should use for the new library. We do some basic auth checking to ensure that the user matches, i.e. I'm not allowed to create a library with Daniel's uploaded LearningPackage. Then we alter key of that LearningPackage to align with the new library's org and slug.
Note on future steps
I do think that at some point we're going to want to have an actual set of models to track these restores and their history + errors, beyond what UserTasks offers. But I don't think that's worth doing for Ulmo.
Referenced from Dave's comment on the parent ticket:
Making a staged restore LearningPackage
The key field needs to be unique across LearningPackages, and the orgs might not match up to anything we have on a new instance. So we're going to encode information from the original archive into it like this:
Example: lib-restore:dave:Axim:problem-bank:1002
In this case, the original archive was lib:Axim:problem-bank. When we generate the LearningPackage, we encode that it's a special "restore" learning package (lib-restore) that dave has just uploaded. The 1002 can just be pulled from the LearningPackage's primary key--we only need it to ensure uniqueness.
Edit: Since we probably want to pass in the key when creating the learning package, it can't be the primary key. We could instead create a short random value and hex-encode it.
Where does the Archive metadata being reported actually live?
The UserTask that we create for the upload process will make at least two artifacts:
Doing the actual Library Creation
We add a new optional arg to the library creation endpoint to take the key of the LearningPackage that we should use for the new library. We do some basic auth checking to ensure that the user matches, i.e. I'm not allowed to create a library with Daniel's uploaded LearningPackage. Then we alter key of that LearningPackage to align with the new library's org and slug.
Note on future steps
I do think that at some point we're going to want to have an actual set of models to track these restores and their history + errors, beyond what UserTasks offers. But I don't think that's worth doing for Ulmo.