Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Schema on Write #23

Open
ghost opened this issue Jul 10, 2014 · 2 comments
Open

Schema on Write #23

ghost opened this issue Jul 10, 2014 · 2 comments

Comments

@ghost
Copy link

ghost commented Jul 10, 2014

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

@loganlinn
Copy link
Member

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.

@ghost
Copy link
Author

ghost commented Jul 30, 2014

Awesome thanks for the reply.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant