Data mapping and validation - in practice

[et-al]

Hello everyone,

Hoping to get some help/guidance with some questions relating to practically implementing using embedded schemas as mappers for the UI, as described here: Data mapping and validation — Ecto v3.12.5

The article explains the concept well & it makes a lot of sense to me, but i dont think the examples give much insight to some of the complexities involved.

1. The example with the accounts / profile, the transaction to insert the data doesnt appear to link it at all i.e. the accounts and profiles are being inserted entirely isolated from each other into their respective database tables. In practice the profile table should link to the user_id / key of the accounts table. I believe this can be done through a multi, or cast_assoc or something similar / combination of the two via a transaction.
2. Following insertion, managing the response when the dataset that was inserted does not match the embedded schema. Validations can be done on the changset prior to massaging/inserting the data accordingly, but should there be errors on the insert relating to constraints etc how do you return those errors to the UI? Is the intention to write some wrapper functions to take the errors from the {:error, changeset} & add them to the changeset being used to generate the UI form for rendering the output errors/messages?
   I still need to look at how the errors are stored in changsets for associations but on the face this seems like it could be quite complex.

Is this a common practice, & how have others handled this in their web applications?

Thanks a lot !!

Daniel

[jan-mb-me]

Sorry, my answer addresses only a part of your question and it’s speculative. But I thought I’d like to share my thoughts anyway (and maybe get some feedback).

@et-al

The example with the accounts / profile, the transaction to insert the data doesnt appear to link it at all i.e. the accounts and profiles are being inserted entirely isolated from each other into their respective database tables. In practice the profile table should link to the user_id / key of the accounts table.

The link (or reference in the database) might be missing by intention. This way one could keep the accounts and the profiles contexts decoupled from each other. The accounts context wouldn’t need to know about the profiles context at all. The profile would just have some account id value and the connection would have to be resolved by a service-like layer/module that depends on both contexts. For the business logic of the profiles context one only needs an account id value, not an account entity, so changes in the accounts context (or the accounts schema) wouldn’t affect the profiles context.