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

Consider adding validators alongside transformers #78

Closed
samisagit opened this issue Dec 18, 2022 · 2 comments · Fixed by #83
Closed

Consider adding validators alongside transformers #78

samisagit opened this issue Dec 18, 2022 · 2 comments · Fixed by #83
Labels
enhancement New feature or request good first issue Good for newcomers

Comments

@samisagit
Copy link
Owner

The only certainty we currently have (assuming there are no bugs in this area) is that the fields of a message sent from natskell to NATS will be of the correct 'type' for NATS to consume (type being a loose definition since they are in a string, but if something is a bool or an int for e.g we can be confident NATS will get that type. However there are cases where values of the correct type are still not valid for e.g an empty string in a mandatory string field is allowed by our client currently.

Adding a new set of functions for loosely validating the values of each field could help mitigate this. A class and class constraint could be added to ensure we're using valid types.

@samisagit samisagit added enhancement New feature or request good first issue Good for newcomers labels Dec 18, 2022
@samisagit samisagit mentioned this issue Jan 1, 2023
1 task
@samisagit
Copy link
Owner Author

It might be worth validating that the byte count sent is actually correct - which would mean storing the bytecount. Not sure now easy this is with the current record syntax used for the transformable types

@samisagit
Copy link
Owner Author

It might be worth validating that the byte count sent is actually correct - which would mean storing the bytecount. Not sure now easy this is with the current record syntax used for the transformable types

We don't need to store it, just need to expose a function that takes the given type and returns the byte count, like the other getters

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

1 participant