We do not use foreign keys (2016)

Re:We do not use foreign keys (2016) by trhway on Saturday November 09, 2019 @01:58AM (#21490078)

> any responsible application should track when that data was read and reject updates if the backing data has changed since it was read... but very few applications even attempt to do this (it's really hard and a huge amount of boilerplate with most APIs).

it is done very simple by versioning. Usually implemented transparently for the data layer API clients.

[ Parent | on HN ]

Re:We do not use foreign keys (2016) by Quekid5 on Tuesday November 19, 2019 @12:16PM (#21575436)

It's simple. I'm just saying that (for most frameworks) it's a lot of work and boilerplate. It's also easy to miss individual cases during code review, etc.

[ Parent | on HN ]

Re:We do not use foreign keys (2016) by lensopra on Tuesday November 19, 2019 @03:03PM (#21577625)

You kind of miss the part where he says "Usually implemented transparently for the data layer API clients." Transparently as in no work, no boilerplate.

I guess your mileage might vary, but Java has JPA/Hibernate, and .NET has Entity Framework, and they both make it easy, so I'm going to be surprised if any major framework or language doesn't make this easy.

The concept is also called optimistic locking, if that makes Googling it easier. Using that term, I easily found that Node.js's Sequelize supports it too https://sequelize.org/v5/manual/models-definition.html#optim...

[ Parent | on HN ]

Re:We do not use foreign keys (2016) by Lord_Zero on Friday November 15, 2019 @11:10AM (#21545982)

SQL Server has a built in ROWVERSION type which plays really nicely with EF Core. Made implementing concurrency checks easy.

[ Parent | on HN ]