fix(ui): the derived data must have an id field with UUID content

[obdulia-losantos]

Reducing validation errors

• If there is an "id" field, the random generated content will be UUID complaint.
• If the Input does not have an "id" field the passthrough mapping will include the #!uuid rule and the "id" field in the derived Entity Type.
• If one of the given Entity Types does not have an "id" field will throw an error.

[lordmallam]

Why must the input schema have an id?. We have basically no control over the shape of expected incoming data.

[obdulia-losantos]

But we have some restrictions on the type and content of data we expect 🤷‍♀️

[obdulia-losantos]

I do not pretend to merge this PR, but I want to bold the fact that sometimes the validation fails due to the random data we generate with the library, and the passthrough mapping without "id" does not pass the validation 😒

[admbtlr]

What do you think @shawnsarwar ?

[shawnsarwar]

Here's my full brain-dump on this. Every entity needs to have an ID that's unique the reason being we want to be able to have durable links between entities. From the kernel side, we need to be able to access any entity via the url /entities/{id-of-entity}. We can either have a fixed field for that ID in the payload as we do now, or complicate things a bit by using an annotation in the schema to specify which payload field is the ID. This is provided for in Avro + salad using @jsonLDPredicate -> type: @id. This is more complex to implement as we then need to understand the schema of each message in order to figure out which field needs to be come the kernel ID. It requires the producer to understand the same.

[shawnsarwar]

To the particulars of this PR. Perhaps when creating a pass-through pipeline, if the input schema does not have a valid UUID in the ID field, one is created. If an ID field is present but isn't a UUID, we have to prepend the old _id field with some signifier and make a new one and properly handle redirection of the old ID to the not_aether_id field.

[obdulia-losantos]

More or less this PR tries to reduce the validation errors.

• If there is an "id" field, the random generated content will be UUID complaint.
• If the Input does not have an "id" field the passthrough mapping will include the #!uuid rule and the "id" field in the derived Entity Type.
• If one of the given Entity Types does not have an "id" field will throw an error.

@lordmallam @shawnsarwar @adamvert is this at least enough?

[shawnsarwar]

@obdulia-losantos I think that should be sufficient.