Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

A stray commit buried multiple levels deep cost me months

droppedasbaby.com

Post reply on HN
Print view View original

21–30 of 38 posts

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

#21

Post by Groxx »

manphone wrote: post #19
jiggawatts wrote: post #13

Earlier quoted context omitted.

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!

Many databases do not actually offer this or pretend to offer this, but it is really just one thing.

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.

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

#22

Post by SoftTalker »

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…

It exists in every industry. Listen to anyone in construction, carpenters, electricians, plumbers, etc.

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

#23

Post by Groxx » 

    # 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. "You can mutate database-connected objects and sometimes they save back to the DB, sometimes they do not" is not reasonable behavior.

(obviously these frameworks exist. quite a few of them. quantity does not in any way imply sanity.)

> 2. DO NOT pass DB models in and out of the DB layer.

Yea, the more I've used "thin" ORMs that give you plain objects, the more I've grown convinced they're the best choice basically all the time. Trying to be magical is cute, but it's guaranteed to be made of spicy unobtanium, and at some point it'll blow up in your face in an extremely convoluted way due to a simple cause that you'll notice is absolutely everywhere and you're just stuck being paranoid forever. There's no need to live like that.

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

#24

Post by unsnap_biceps »

manphone wrote: post #19
jiggawatts wrote: post #13

Earlier quoted context omitted.

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!

Many databases do not actually offer this or pretend to offer this, but it is really just one thing.

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?

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

#25

Post by Stitch4223 »

saghm wrote: post #12
Stitch4223 wrote: post #3

Earlier quoted context omitted.

With great power comes great responsibility.

Yes, and the people who designed that API clearly were not worthy of of the responsibility of providing it

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.

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

#26

Post by ricardobeat »

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.

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

#27

Post by andreareina »

magicalhippo wrote: post #16

I found the article very hard to follow. Then I read the domain name and it all made sense... Guess our pattern is different, not really felt the pain point the author is talking about. Or it's the language/framework, not sure whatever the example code is written in, but setting properties on entity records would never update the database in the ones I've used. When we did things more manually we'd make sure that met…

This is the Active Record pattern, I used to hear about it all the time. Don't know if the zeitgeist has changed or if I'm just around different parts of the internet these days.

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

#28

Post by saghm »

Stitch4223 wrote: post #25
saghm wrote: post #12

Earlier quoted context omitted.

Yes, and the people who designed that API clearly were not worthy of of the responsibility of providing it

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

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

#29

Post by jiggawatts »

unsnap_biceps wrote: post #24
manphone wrote: post #19

Earlier quoted context omitted.

Many databases do not actually offer this or pretend to offer this, but it is really just one thing.

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

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

#30

Post by grebc »

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.
Post reply on HN