Hi Jeremy,
First of all, thank you. I'm really happy that you've unified validations
and constraints. I found their separation to be a source of bugs and
confusion.
I've moved a small project over to the current version of the
extension/plugin and have three short comments.
If you look at the snippet below, you'll see that I've purposely left some
redundant elements in the column and validation/constraint specification:
String :name, null: false
citext :url, null: false, unique: true
...
validate do
presence [:name, :url]
max_length 255, [:name, :url]
...
unique :url
end
I *believe* this is not an issue, but my question is if it would be clearer
to extend the behaviour of the existing column options (i.e. null and
unique), once the extension is loaded. Many of the column types also
include implicit size constraints, which could possibly be inferred.
My second comment is a "nice to have," which would be to include basic
numerical checks, i.e. an integer field is greater than 0.
Lastly, and I'm not even sure if this is good practice, I tend to add
validates_presence against association accessors (i.e. thing, not
thing_id), with the purpose of avoiding having the DB raise reference
errors. Would it be possible to use the existing foreign_key helper to
generate minimal does-this-reference-exist checks in the application?
Once again, thank you! I've even noticed a speed-up during testing.
Regards,
Jamie Hodge
--
You received this message because you are subscribed to the Google Groups
"sequel-talk" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/sequel-talk/-/U2vrBffJxk0J.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sequel-talk?hl=en.
