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

11–20 of 38 posts

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

#11

Post by hackthemack »

UqWBcuFx6NV4r wrote: post #5
Stitch4223 wrote: post #3

Earlier quoted context omitted.

With great power comes great responsibility.

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 it all the time... for the past 35 years.

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

#12

Post by saghm »

Stitch4223 wrote: post #3
Retr0id wrote: post #2

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

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

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

#13

Post by jiggawatts »

Retr0id wrote: post #2

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

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!

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

#14

Post by hparadiz »

Feel like I've solved this non problem like 20 times.

If your framework is holding your records in a collection and you keep track of phantoms that have been edited but not saved as they are edited then all this becomes a non issue. That way you do Collection->SaveTransaction or Collection->Save() and the collection does all the db commit, roll back nonsense.

Anyway the examples I don't even know if I could call that an ORM. Use a better one.

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

#16

Post by magicalhippo »

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 methods like `create_main_records` would start a transaction if not in one, and only commit if it started the transaction. This way we could nest without worry. Our database supported nested transactions but using this pattern we didn't feel the need.

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

#17

Post by 123sereusername »

Retr0id wrote: post #8
offbyone42 wrote: post #6

Earlier quoted context omitted.

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.

What's the use case? I've never found myself wishing my transaction wasn't actually atomic.

[dead]

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

#18

Post by p-e-w »

offbyone42 wrote: post #6
Retr0id wrote: post #2

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

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.

The option to make a transaction not be a transaction? What is it then?

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

#19

Post by manphone »

jiggawatts wrote: post #13
Retr0id wrote: post #2

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

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.

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

#20

Post by nine_k »

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…

Tired: pass live DB model objects around, mutate them to accumulate random changes, call commit() five levels deep, experience the chaos as described by the author.

Wired: fetch DB records and construct domain objects, pass them around, do mutation on the outermost level within an explicit transaction. (Typical best practice.)

Inspired: "functional core, imperative shell".

Post reply on HN