3 ms·

True, but for example with db-level validations I don’t have to worry that a new developer ships a batch job that runs raw inserts for performance reasons and b

True, but for example with db-level validations I don’t have to worry that a new developer ships a batch job that runs raw inserts for performance reasons and bypasses app layer validations.

zepolen 2y ago
What? You should be exposing your data access layer as a microservice and all your db level validations should be done there... You can even write a small DSL syntax language to make it easier to use for developers, and perhaps an Obviously Reduntant Middleware that sits between them to convert their programming language objects to the DSL. Add some batch support, perhaps transactional locks (using mongo, we want to be webscale after all) and perhaps a small terminal based client and voila, no one should ever need to deal with petty integrity in the db again.
- deleted 2y ago
  [deleted]
- eropple 2y ago
  This post is a fantastic example of Poe's Law. You had me for a second.
goosejuice 2y ago
I'm not advocating for no database level validations. One can and should have both in my opinion. Postgres supports constraints on jsonb as well. I would generally advocate for no write access outside of the app as well. Certainly for new developers. Get some tests on that batch job.
- corytheboyd 2y ago
  > I would generally advocate for no write access outside of the app as well. FWIW I think OP was referring to app code still, but code opting in to skipping app data validations. Rails for example makes this very easy to do, and there are tons and tons of people out there selling this as a performance improvement (this one trick speeds up bulk operations!!!!). There are times where it’s useful, but it’s a very sharp knife that people can easily misuse. So yeah, anyway, have both db constraints and app validations.
  - goosejuice 2y ago
    Thanks for pointing that out, I did misread that and have seen/written such things in rails land. We used active record import which gives the option of running validations. But yeah, layering your safety nets is generally wise. I would include testing and code review in that as well.

True, but for example with db-level validations I don’t have to worry that a new developer ships a batch job that runs raw inserts for performance reasons and bypasses app layer validations.

zepolen 2y ago

What? You should be exposing your data access layer as a microservice and all your db level validations should be done there... You can even write a small DSL syntax language to make it easier to use for developers, and perhaps an Obviously Reduntant Middleware that sits between them to convert their programming language objects to the DSL. Add some batch support, perhaps transactional locks (using mongo, we want to be webscale after all) and perhaps a small terminal based client and voila, no one should ever need to deal with petty integrity in the db again.

deleted 2y ago
[deleted]
eropple 2y ago
This post is a fantastic example of Poe's Law. You had me for a second.

goosejuice 2y ago

I'm not advocating for no database level validations. One can and should have both in my opinion. Postgres supports constraints on jsonb as well. I would generally advocate for no write access outside of the app as well. Certainly for new developers. Get some tests on that batch job.

corytheboyd 2y ago
> I would generally advocate for no write access outside of the app as well. FWIW I think OP was referring to app code still, but code opting in to skipping app data validations. Rails for example makes this very easy to do, and there are tons and tons of people out there selling this as a performance improvement (this one trick speeds up bulk operations!!!!). There are times where it’s useful, but it’s a very sharp knife that people can easily misuse. So yeah, anyway, have both db constraints and app validations.
- goosejuice 2y ago
  Thanks for pointing that out, I did misread that and have seen/written such things in rails land. We used active record import which gives the option of running validations. But yeah, layering your safety nets is generally wise. I would include testing and code review in that as well.