You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is more of a question than an issue, but it looks like the schema being applied to components with defcomponent[k] is done on the read, i.e. when you perform a build, whatever data happens to be in a given cursor will be validated against a schema.
Is there any to validate the data going in on the write? That is, on the transact/update call so that the offending party can be caught more easily than having to backtrack from the validation error on read. It's possible I'm missing something of course and maybe this already occurs somehow, but I was hoping for some clarification or discussion on the issue and what the thought process was to implement it in its current form.
Thanks,
Tom
The text was updated successfully, but these errors were encountered:
Hey Tom, my apologies for the delayed response. There's currently not a way to specify that cursor validation should happen each time a component updates. As a workaround, you can manually call schema validate from will-update of component. You could probably do this via mixin to make it re-usable. That said, there are plans to enhance schema support by handling default schema metadata like, ^:always-validate from defcomponent/defcomponentk, which may make sense to validate on each update.
Hi there,
This is more of a question than an issue, but it looks like the schema being applied to components with defcomponent[k] is done on the read, i.e. when you perform a build, whatever data happens to be in a given cursor will be validated against a schema.
Is there any to validate the data going in on the write? That is, on the transact/update call so that the offending party can be caught more easily than having to backtrack from the validation error on read. It's possible I'm missing something of course and maybe this already occurs somehow, but I was hoping for some clarification or discussion on the issue and what the thought process was to implement it in its current form.
Thanks,
Tom
The text was updated successfully, but these errors were encountered: