Support algebraic types in schema

[bedeho]

Support algebraic types in schema

[bedeho]

Extra note upon further reflection

Its clear that the flattened variant actually is not feasible. This is because, a key requirement is to be able to filter on the state encoded using the OpenCrud functionality of the resulting API, and that is not possible. A specific example: its not possible to only select married persons, that is an encoding with the case MarriedTo, you could only filter on a person a married to some other specific person for some number of years MarriedTo(/*Spouce */ Person, /* years married*/ u32),, which is useless.

Conclusion: Flatten is not feasible

This then begs the question of how things works out in the fourth alternative. Here one would have to radically extend the OpenCrud interface generated to incoroprate some sort of matching functionality, similar to the ... on Variant {} capability native to GraphQL on union types. While in principle I don't see it cannot be done, I would not be surprised if it cannot, but more importantly: it will involve a great deal of work.

Conclusion: Intoducing algebraic types, even if possible, will be extremly time consuming

[bedeho]

Extra note v2.0:

It is actually possible to sidestep the heavy work on the API side, described on the prior issue if we expose the low-level database fields that encode what variants are active, and also the payload fields. This means the end-user will get a representation which is the union of approach 2 and 4 above.

[bedeho]

We decided that, we will go with approach 2 for now, then see how hard that is to work with before we invest in anything else.

[dzhelezov]

Algebraic types were introduced with certain limitations: https://dzhelezov.gitbook.io/hydra/docs/schema-spec/variant-types