3 ms·

I mean there is a reason why postgres and similar have things like row level locks in addition to the normal transaction isolation levels. But the sad truth is

I mean there is a reason why postgres and similar have things like row level locks in addition to the normal transaction isolation levels. But the sad truth is that in my experience the huge majority of software engineers (which are not explicit some DB people) do not properly understand SQL transaction and the guarantees it gives. Most times because they are simply not aware about all the many things they are not aware of when it comes to it. And especially repeatable read is ... a mess, it comes with many of the complexity drawbacks of serializable transaction while not having quite the guarantees serializable has opening up the possibility for subtle bugs making writing complicated db interactions harder and to top it of depending on the db and db usage characteristics of you application it might not even be much faster.

ElectricalUnion 3y ago
Is this "just" them not knowing DB isolation levels, or some ORM "layer" rug-pulling from under them? To me ORMs in general have often too many layers of implicit and surprising behavior. And in a vain attempt to hide their ugly and complex faces, often the situation is made even worse by putting more "layers" in front of them. Now besides being a specialist in your language, you also need to have somewhat deep knowledge of your DBMS, your DBMS driver, your ORM and in all the layers someone put in front of the ORM, just to not shoot yourself on the foot in a spectacular fashion.
- dathinab 3y ago
  > Is this "just" them not knowing DB isolation levels yes in the cases where I had been working with an ORM in recent years it where "thin" ORMs which didn't really change anything about transactions/isolation levels nor had any abstractions which seem like they might do additional synchronizations or anything like that (they where mainly query builder + some small amount of ORM parts)

ElectricalUnion 3y ago

Is this "just" them not knowing DB isolation levels, or some ORM "layer" rug-pulling from under them? To me ORMs in general have often too many layers of implicit and surprising behavior. And in a vain attempt to hide their ugly and complex faces, often the situation is made even worse by putting more "layers" in front of them. Now besides being a specialist in your language, you also need to have somewhat deep knowledge of your DBMS, your DBMS driver, your ORM and in all the layers someone put in front of the ORM, just to not shoot yourself on the foot in a spectacular fashion.

dathinab 3y ago
> Is this "just" them not knowing DB isolation levels yes in the cases where I had been working with an ORM in recent years it where "thin" ORMs which didn't really change anything about transactions/isolation levels nor had any abstractions which seem like they might do additional synchronizations or anything like that (they where mainly query builder + some small amount of ORM parts)