DB constraints for model validation

[motasem-salem]

There are two different opinions:

1 - Use DB level constraints in addition to model validations.
2 - Rely only on model validations.

Original discussion: #24 (diff)

[motasem-salem]

I vote for 1

[PurityControl]

For model validation I vote for 1 - db validation.
If there is resistance to it I don't mind only model validation.
However having some things we validate at the db level and not others is something I am quite strongly against.

[sampritipanda]

I vote for 2.

Like @PurityControl I am against having some validations in the db and others in the model. I think all of the validations should be done in the model. The database should be only used for uniqueness validations using indexes.

As I have said before, you can't have all the validations in the DB; but you can have all the validations in the model.

[tochman]

I usually don't refer to conventions and best practice so I just state my personal opinion: I would definitely put all validations in the model. ;-)

[yggie]

there should only be one source of truth in my opinion, model validations can be seen at a glance. So its a 2 for me 😉

[NikitaAvvakumov]

Voting for 1.
Importantly, as we discussed, models remain as the one single source of truth, the db merely conforms to it and backs it up. Models retain all validations, nothing is deferred to the db.

[techsailor]

I'm not voting but just highlighting uniqueness issue from rails tutorial

Using validates :uniqueness does not guarantee uniqueness.

D’oh! But what can go wrong? Here’s what:

Alice signs up for the sample app, with address alice@wonderland.com.
Alice accidentally clicks on “Submit” twice, sending two requests in quick succession.
The following sequence occurs: request 1 creates a user in memory that passes validation, request 2 >does the same, request 1’s user gets saved, request 2’s user gets saved.
Result: two user records with the exact same email address, despite the uniqueness validation.
If the above sequence seems implausible, believe me, it isn’t: it can happen on any Rails website with >significant traffic. Luckily, the solution is straightforward to implement; we just need to enforce >uniqueness at the database level as well. Our method is to create a database index on the email >column, and then require that the index be unique.

But I would lean towards model validations personally in the majority, but a few db validations (where critical) might be useful too.

[PurityControl]

@techsailor nice insight

[PurityControl]

I think some of the comments suggest there is confusion. The vote is not for one or the other, it is whether we implement db constraints on top of model validations.
Not having model validations is not an option.

[yggie]

Thanks for clarifying @PurityControl 😀, I obviously didn’t read the description correctly. Well my opinion is then to avoid DB validations for the time being. At present, it doesn't add much value, and is much harder to keep track of and change. If you find a need to add it (for a more robust validation), the database constraints can still be added in a separate PR on top of the model validations. Although I find it highly unlikely given the use case that you would ever experience race conditions (especially if you are running on just a single dyno on Heroku), so it is premature optimization at this point.

[betasve]

I tend to agree with @yggie. Definitely voting for (2). I am concerned about the cases of email duplication, because of double-clicking a button. Unfortunately according to my observations, lots of newbie internet users are doing it. They think the in-browser env is the same like their desktop. Pretty lame if you as me :) Nevertheless if this duplication happens only when the user double-clicks and server is overloaded, then the chance of this happening is small.
I voted for option 2, mostly because I think this is the agile way. No need to implement something of questionable value at this stage of the project.

[NikitaAvvakumov]

@yggie Point taken - at the present moment, this is probably overkill. However, going forward with a constantly changing distributed team, where the people working on the app tomorrow may be entirely different from the ones working on it today, it will be too easy to miss the moment where database-level constraints become valuable or even necessary. The app's primary purpose is data management and manipulation, it is essentially an online database. As such, data integrity should be very high on our list of priorities. Database constraints are the tools made for this purpose, and can guard not only against invalid user input but also against the actions of an ill-informed developer.

[yggie]

@betasve to address your concern, we need to look deeper into how Rails works underneath. Rails is essentially single-threaded, which means it can only process one request at a time. Taking @techsailor's quoted example of Alice accidentally clicking twice, the two requests sent will be resolved in the order that they are sent. By the time the second request is ready to be processed, with the appropriate model constraints, it will be rejected. Not to say Rails can't process requests in parallel, but with the default configuration, we won't see this problem anytime soon.