A stray commit buried multiple levels deep cost me months • Hacker News Board

Re: A stray commit buried multiple levels deep cost me months

#31

Post by grebc » Sun, Aug 02, 2026, 7:46 AM UTC

ricardobeat wrote: post #26

Groxx wrote: post #23

# transaction has been commented out # with transaction(): db_models = DBAccess.fetch_records(ids) db_models[0].yo_mama_fat = True # request ends, data poofs into the ether tbh if this doesn't fail either immediately (no open transaction == error on modification attempt) or at GC time (if there's some kind of deferred logic), then I'd say this is an extremely bad framework and it does hold a major part of the blame.…

I think the code doesn't fail because it never existed. AI slop.

Either a bad acid trip or AI fever dreams.

Re: A stray commit buried multiple levels deep cost me months

#32

Post by Stitch4223 » Sun, Aug 02, 2026, 8:58 AM UTC

saghm wrote: post #28

Stitch4223 wrote: post #25

Earlier quoted context omitted.

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.…

> 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…

Yes, a great API built on a capable database helps in those cases :)

Re: A stray commit buried multiple levels deep cost me months

#33

Post by saghm » Sun, Aug 02, 2026, 1:44 PM UTC

Stitch4223 wrote: post #32

saghm wrote: post #28

Earlier quoted context omitted.

> 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…

Yes, a great API built on a capable database helps in those cases :)

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.

Re: A stray commit buried multiple levels deep cost me months

#34

Post by saghm » Sun, Aug 02, 2026, 1:50 PM UTC

hackthemack wrote: post #11

UqWBcuFx6NV4r wrote: post #5

Earlier quoted context omitted.

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

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 i…

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.

Re: A stray commit buried multiple levels deep cost me months

#35

Post by Stitch4223 » Sun, Aug 02, 2026, 3:31 PM UTC

saghm wrote: post #33

Stitch4223 wrote: post #32

Earlier quoted context omitted.

Yes, a great API built on a capable database helps in those cases :)

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…

Ah yes. I read it differently. I agree that this can could be prevented with a decent API and that writing such facility is a challenge on it’s own. It would have helped the developers in the article to write better code as a result.

Re: A stray commit buried multiple levels deep cost me months

#36

Post by Groxx » Sun, Aug 02, 2026, 3:33 PM UTC

grebc wrote: post #30

Groxx wrote: post #23

# transaction has been commented out # with transaction(): db_models = DBAccess.fetch_records(ids) db_models[0].yo_mama_fat = True # request ends, data poofs into the ether tbh if this doesn't fail either immediately (no open transaction == error on modification attempt) or at GC time (if there's some kind of deferred logic), then I'd say this is an extremely bad framework and it does hold a major part of the blame.…

Dapper in .NET is f*cking fantastic. I've not found a better library/pattern for SQL data access.

At a glance that looks like exactly what I like, yeah. Object mappers are 100% worth the effort and are often faster than hand translating the objects (because they'll cache and do things that are annoying or error-prone to do by hand) (code generation is nice too, Android has a couple that do that), and plain inline SQL strings with vars are FAR easier to learn and reason about and can take advantage of any database and any feature, including custom ones.

Re: A stray commit buried multiple levels deep cost me months

#37

Post by saghm » Sun, Aug 02, 2026, 9:03 PM UTC

Stitch4223 wrote: post #35

saghm wrote: post #33

Earlier quoted context omitted.

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…

Ah yes. I read it differently. I agree that this can could be prevented with a decent API and that writing such facility is a challenge on it’s own. It would have helped the developers in the article to write better code as a result.

Fair enough; I did initially mention the API specifically as the issue, but it's also probably obvious by now that I have pretty strong opinions about API design as worthy of its own consideration, so it's possible I might have mistakenly assumed it was more clear what I was talking about for people who don't focus on it as much as I do

Re: A stray commit buried multiple levels deep cost me months

#38

Post by unsnap_biceps » Wed, Aug 05, 2026, 3:09 AM UTC

jiggawatts wrote: post #29

unsnap_biceps wrote: post #24

Earlier quoted context omitted.

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?

Literally: BEGIN TRAN BEGIN TRAN COMMIT TRAN ROLLBACK TRAN

Yes, but what part about that is pretend? Is there a db that doesn't do the right thing and roll back the outer transaction? If so, can you name it?