Mark documents with the component that created them.

[SilasBerger]

Context: I believe there are valid reasons for letting multiple frontend components use the same document type. However, consider the following scenario:

1. I implement a component <Foo> and use a new document typ something_generic with that component.
2. I implement another component <Bar>, which happens to fit the exact data model of the something_generic document type – so, I reuse that type.
3. <Foo> and <Bar> now both save documents of type something_generic.

Problem: <Foo> evolves over time and now requires a completely different data model. <Bar>, however, hasn't changed and isn't expected to. So, I now need a new document type something_else and I need to migrate all <Foo>-related documents to that new type. This is problematic: How can I select and modify all something_generic documents that were created by <Foo>, without affecting those created by <Bar>

Suggested solution: Add a new component column to the document table. When saving a document of type something_generic, the <Foo> component would set component to Foo while <Bar> would set it to Bar. That way, when the above scenario occurs, we can SELECT * FROM documents WHERE type='something_generic' AND component='Foo'; and migrate all those documents to the new something_else type.

Disadvantage: We would be saving an additional field for every document that is never read under normal circumstances.

Alternative solution: Implement the component field on the document_root. With that, we would only have to persist the field once per instance of each component in the frontend.

[SilasBerger]

An alternative approach: That same transition from one document type to another could also be handled by the frontend. This will be a rare case anyway, so it wouldn't be a big issue to have some legacy handling here and there.

The one thing that could make this issue more frequent is users wanting to implement custom document-based components without wanting to have to fork the API, since their changes to the API (to accommodate a new document typ). My original idea, together with some rather generic document types, is one way to mitigate this limitation. A more elegant approach would be to include this question in the discussion outlined here: GBSL-Informatik/teaching-dev#150.

Basically, we would just need to provide an interface that lets users include custom document types in a file that likely won't be affected by a future upgrade from teaching-api. I haven't given this much thought yet, but it seems like this should be rather easy.

[lebalz]

I see your point absolutely, but i don't like the idea of storing implementation-details on the backend. When a dev/client wants this behavior, he always could add information about which component registered a model to the data field of the model...

Regarding the concerns of clashing document types - this seems real and should be handled indeed.
I suggest to use prefixes, as it's done for the NavItems: https://github.com/GBSL-Informatik/teaching-dev/blob/main/src/theme/NavbarItem/ComponentTypes.tsx
--> custom document types not implemented by the "core" could/should always be prefixed with something (custom- might be too verbose, i could think of single character prefixes as + or @ or $.)