Analysis: Can we change default data format to JSON? And if so, how?

Altinn / app-lib-dotnet

Libraries used in Altinn Apps

BSD 3-Clause "New" or "Revised" License

8 stars 11 forks source link

Analysis: Can we change default data format to JSON? And if so, how? #892

Open TheTechArch opened 4 years ago

TheTechArch commented 4 years ago

Description

Today the app data is stored as XML in Storage. To reduce the amount of data store, and to make life simpler for app developers, we need to change the default storage format to JSON.

Default to XML if config is not set, but set JSON as default in config in app template.

Considerations

Input (beyond tasks) on how the user story should be solved can be put here. Can we handle change of data format for already deployed app?

Acceptance criteria

Data is stored in Storage as JSON as default
It is possible to change at dataElementType level to set different formats.

Development tasks

[ ] Task 1
[ ] Task 2 etc

Definition of done

Verify that this issue meets DoD (Only for project members) before closing.

[ ] Documentation (if relevant)
[ ] Manual test (if needed)
[ ] Automated test (if needed)
[ ] QA
[ ] Test
[ ] All tasks in this userstory are closed (i.e. remaining tasks are moved to other user stories or marked obsolete)

RonnyB71 commented 3 years ago

@altinnadmin @TheTechArch In order for this to be solved we must first make sure that the produced JSON structure validates according to the JSON Schema. Right now it's only the XML that validates against the XSD as the JSON lacks a named root and hence is "one level below" the XML with regards to the data structre.

altinnadmin commented 3 years ago

@RonnyB71 @TheTechArch Interesting... So we have the same problem with JSON as we recently had with XML?

Have we verified that "broken" XML in Storage will work with an updated datamodel class for the apps in production that is affected by the XML problem?

Also, this sheds some new light on this discussion about JSON as prefill. We now probably have an external dependency on a bug in our implementation...

I guess this should be a top priority to get fixed asap.

RonnyB71 commented 3 years ago

@altinnadmin @TheTechArch yes sort of. The root object isn't named in JSON as it is in XML. The way it's solved today is that the class is named after the first property in the object which typically is 'melding' from SERES and 'skjema' from OR. This results in a JSON where this level is lost. For XML this works fine as the root node is serialized into the class. I've discussed this a bit with Bendik and looked at how others have solved this, and one solution is to take the Schema name into account when naming the class like this: https://quicktype.io/csharp

nkylstad commented 8 months ago

closing this issue as stale.

ivarne commented 3 weeks ago

I had this in mind when doing the rewrite for multiple data models. We store the mime type on data elements, and the allowedContentTypes on the data type, so the only change would be to respect if the first allowed content type would be application/json when creating data elements.