4 ms·
I'm not really sure that would help in the case we had. Most of our code ran through an ORM, and the ORM assumes the DB either did what it asked, or the query
by lostapathy 8y ago
I'm not really sure that would help in the case we had.
Most of our code ran through an ORM, and the ORM assumes the DB either did what it asked, or the query fails. I don't want to have to abandon my ORM because I can't trust my "DBA" to not sabotage my queries.
- matte_black 8y agoThis is just a limitation of ORMs. After a certain complexity you really should just be making direct queries to your database and not relying on ORMs.
- lostapathy 8y agoThat’s the thing -what the app tier was doing wasn’t to complex for an ORM. Not by a long ahot. The triggers that caused us problems generally came about to cover unrelated dba laziness and needed removed for sanity reasons anyway. I am not arguing there cannot be a good case for triggers, just that when abused they cause a certain level of hell that is not worth it.
- fredrikfornwall 8y agoA properly written trigger shouldn't throw away data silently. It should raise an exception, which indeed would cause the query to fail, and roll back the whole transaction (so no side effect is committed at all). https://www.postgresql.org/docs/current/static/plpgsql-errors-and-messages.html https://www.postgresql.org/docs/current/static/plpgsql-error...
- blattimwind 8y agoA good ORM allows you to specify that a column may be changed server-side by triggers etc. on an update (or insert), and it will then make sure to retrieve the correct value after the fact, if necessary.