4 ms·

> DO NOT blame the framework Why not? Why should I be allowed to db.commit() midway through a transaction?

by Retr0id 3mo ago

Stitch4223 3mo ago
With great power comes great responsibility.
- Retr0id 3mo ago
  Well, I don't want either. Give me a safe API!
- UqWBcuFx6NV4r 3mo ago
  This is like people saying that C is infallible and it’s those stupid lesser-developers that unlike me simply cannot wield its immense power. No. Usability matters. After all these years software development still has an ‘unfounded male confidence / posturing’ problem and it’s just cringeworthy
  - hackthemack 3mo ago
    I agree. No matter how complicated, or unnecessary, or unintuitive a piece of software or technology is... There is always this contingent of people who pop in and say "It is not that hard!" and furthermore tend to express a view of "I am superior because I figured out this obtuse thing, and you must be inferior because you have not figured it out". I do not know why that mentality exists in the industry, but I see it all the time... for the past 35 years.
    - SoftTalker 3mo ago
      It exists in every industry. Listen to anyone in construction, carpenters, electricians, plumbers, etc.
    - saghm 3mo ago
      I've long felt that skill in designing APIs is hugely underrated in software. There's a common perception that what happens under the hood is complicated and requires being very smart, but the crafting a way to interact with a system that prevents issues when possible and at least tries to encourage usage patterns that will not lead to users shooting themselves in the foot is trivial enough to handwave away. All of the bugs and vulnerabilities that could have been completely avoided by a different API design seem to get classified the user's fault, not whoever designed the API.
- saghm 3mo ago
  Yes, and the people who designed that API clearly were not worthy of of the responsibility of providing it
  - Stitch4223 3mo ago
    No. Exposing primitives like commit or “begin transaction” isn’t bad or irresponsible design; working with databases is ridiculously hard, which becomes apparent when demand increases. Combining that with spaghetti that does transaction magic at random places guarantees the sort of pain that makes cursing the entire human race seem like a pretty mild response. Higher-level abstractions may prevent some footguns; e.g., an “atomic” decorator/annotation commits automatically after a successful call. They are somewhat easier to understand but come with their own limitations and caveats.
    - saghm 3mo ago
      > No. Exposing primitives like commit or “begin transaction” isn’t bad or irresponsible design; working with databases is ridiculously hard, which becomes apparent when demand increases. The problem isn't being able to commit. The problem is being able to commit and then not notice that you're no longer in the transaction. You could easily have `begin_transaction` return a `Transaction` object, having operations in the transaction happen on the object, and calling `commit` on it makes it throw an error if you try to use it again after. Maybe the reason that working with databases is "ridiculously hard" because the API isn't well-designed...
      - Stitch4223 3mo ago
        Yes, a great API built on a capable database helps in those cases :)
        saghm 3mo ago
        I don't understand what this has to do with the database being used. There's nothing preventing designing an API for any database with transactions that has the flaw I described, or from using a technique like I described to prevent that flaw. You told me "No" when I pointed out that a responsible API developer would not make an API like that. Now you're shifting to make some unrelated point about the database itself. I feel like you're implicitly assuming that the same people who write the database internals need to be the ones writing the code that provides a high-level client library that will be used by applications that need to interact with the database from the outside, and I don't agree with that premise at all. If anything, the fact that database internals are so complicated to get write is an argument in favor of having separate developers with different specialties, and not just slapping together an API without thinking about it because you're too busy working on the internals.
offbyone42 3mo ago
Giving "I cut my finger with a knife, why is the knife so sharp?" energy. JKJK. I think the option should be there, but it needs to be used responsibly.
- p-e-w 3mo ago
  The option to make a transaction not be a transaction? What is it then?
- Retr0id 3mo ago
  What's the use case? I've never found myself wishing my transaction wasn't actually atomic.
  - 123sereusername 3mo ago
    [dead]
jiggawatts 3mo ago
Database engines I've worked with generally support nested transactions, so you can open a transaction, open another transaction, commit it, then roll back the outer transaction... and it's like nothing ever happened. This ability to compose transactions is their main benefit over other kinds of concurrency control!
- manphone 3mo ago
  Many databases do not actually offer this or pretend to offer this, but it is really just one thing.
  - Groxx 3mo ago
    For those that don't, it's almost always modeled in the connection-library as "hold it open until commits == opens, or roll back if any roll back". Or it's often easy to build this yourself, around the library. Which works entirely fine in most cases. You're at greater risk of phantom reads and general "stuff that can occur while you hold open a transaction", but if you're not handling that correctly then you're not handling that correctly. It's only a matter of volume, not existence. ... with a clear exception for cases where you do need to truly end a transaction, like if you're relying on some other thread to do something on a different transaction that needs to see your changes, or when you risk a deadlock somewhere due to not releasing your lock. Those are both a risky patterns for a lot of reasons though, and worth avoiding at design-time if at all possible.
  - unsnap_biceps 3mo ago
    Are you referring to save points as the "pretend to offer this"? If so, why wouldn't they work? If not, what are you referring to?
    - jiggawatts 3mo ago
      Literally: BEGIN TRAN BEGIN TRAN COMMIT TRAN ROLLBACK TRAN

> DO NOT blame the framework Why not? Why should I be allowed to db.commit() midway through a transaction?

by Retr0id 3mo ago

> DO NOT blame the framework Why not? Why should I be allowed to db.commit() midway through a transaction?

Stitch4223 3mo ago

With great power comes great responsibility.

Retr0id 3mo ago
Well, I don't want either. Give me a safe API!
UqWBcuFx6NV4r 3mo ago
This is like people saying that C is infallible and it’s those stupid lesser-developers that unlike me simply cannot wield its immense power. No. Usability matters. After all these years software development still has an ‘unfounded male confidence / posturing’ problem and it’s just cringeworthy
- hackthemack 3mo ago
  I agree. No matter how complicated, or unnecessary, or unintuitive a piece of software or technology is... There is always this contingent of people who pop in and say "It is not that hard!" and furthermore tend to express a view of "I am superior because I figured out this obtuse thing, and you must be inferior because you have not figured it out". I do not know why that mentality exists in the industry, but I see it all the time... for the past 35 years.
  - SoftTalker 3mo ago
    It exists in every industry. Listen to anyone in construction, carpenters, electricians, plumbers, etc.
  - saghm 3mo ago
    I've long felt that skill in designing APIs is hugely underrated in software. There's a common perception that what happens under the hood is complicated and requires being very smart, but the crafting a way to interact with a system that prevents issues when possible and at least tries to encourage usage patterns that will not lead to users shooting themselves in the foot is trivial enough to handwave away. All of the bugs and vulnerabilities that could have been completely avoided by a different API design seem to get classified the user's fault, not whoever designed the API.
saghm 3mo ago
Yes, and the people who designed that API clearly were not worthy of of the responsibility of providing it
- Stitch4223 3mo ago
  No. Exposing primitives like commit or “begin transaction” isn’t bad or irresponsible design; working with databases is ridiculously hard, which becomes apparent when demand increases. Combining that with spaghetti that does transaction magic at random places guarantees the sort of pain that makes cursing the entire human race seem like a pretty mild response. Higher-level abstractions may prevent some footguns; e.g., an “atomic” decorator/annotation commits automatically after a successful call. They are somewhat easier to understand but come with their own limitations and caveats.
  - saghm 3mo ago
    > No. Exposing primitives like commit or “begin transaction” isn’t bad or irresponsible design; working with databases is ridiculously hard, which becomes apparent when demand increases. The problem isn't being able to commit. The problem is being able to commit and then not notice that you're no longer in the transaction. You could easily have `begin_transaction` return a `Transaction` object, having operations in the transaction happen on the object, and calling `commit` on it makes it throw an error if you try to use it again after. Maybe the reason that working with databases is "ridiculously hard" because the API isn't well-designed...
    - Stitch4223 3mo ago
      Yes, a great API built on a capable database helps in those cases :)
      - saghm 3mo ago
        I don't understand what this has to do with the database being used. There's nothing preventing designing an API for any database with transactions that has the flaw I described, or from using a technique like I described to prevent that flaw. You told me "No" when I pointed out that a responsible API developer would not make an API like that. Now you're shifting to make some unrelated point about the database itself. I feel like you're implicitly assuming that the same people who write the database internals need to be the ones writing the code that provides a high-level client library that will be used by applications that need to interact with the database from the outside, and I don't agree with that premise at all. If anything, the fact that database internals are so complicated to get write is an argument in favor of having separate developers with different specialties, and not just slapping together an API without thinking about it because you're too busy working on the internals.

offbyone42 3mo ago

Giving "I cut my finger with a knife, why is the knife so sharp?" energy. JKJK. I think the option should be there, but it needs to be used responsibly.

p-e-w 3mo ago
The option to make a transaction not be a transaction? What is it then?
Retr0id 3mo ago
What's the use case? I've never found myself wishing my transaction wasn't actually atomic.
- 123sereusername 3mo ago
  [dead]

jiggawatts 3mo ago

Database engines I've worked with generally support nested transactions, so you can open a transaction, open another transaction, commit it, then roll back the outer transaction... and it's like nothing ever happened. This ability to compose transactions is their main benefit over other kinds of concurrency control!

manphone 3mo ago
Many databases do not actually offer this or pretend to offer this, but it is really just one thing.
- Groxx 3mo ago
  For those that don't, it's almost always modeled in the connection-library as "hold it open until commits == opens, or roll back if any roll back". Or it's often easy to build this yourself, around the library. Which works entirely fine in most cases. You're at greater risk of phantom reads and general "stuff that can occur while you hold open a transaction", but if you're not handling that correctly then you're not handling that correctly. It's only a matter of volume, not existence. ... with a clear exception for cases where you do need to truly end a transaction, like if you're relying on some other thread to do something on a different transaction that needs to see your changes, or when you risk a deadlock somewhere due to not releasing your lock. Those are both a risky patterns for a lot of reasons though, and worth avoiding at design-time if at all possible.
- unsnap_biceps 3mo ago
  Are you referring to save points as the "pretend to offer this"? If so, why wouldn't they work? If not, what are you referring to?
  - jiggawatts 3mo ago
    Literally: BEGIN TRAN BEGIN TRAN COMMIT TRAN ROLLBACK TRAN