O/RM is like adding brain damage to your database

I can imagine the following situation (with or without ORM, it doesn't matter):

The manager tells John to update the user name to "Pepe" and the boss tells Jane to update the user name to "Juan", both proceed at the same time and hit the button at the same time (that's unlikely to happen due to the same time meaning the same absolute time but let's imagine it's possible)

Both hit the button at the same time "SUBMIT".

Which name will the user have? You can't know without looking at the DB.

Let's imagine the difference between John and Jane hitting the button is of 1ms, being John the first one and Jane the second one.

Which name will the user have? Again you can't know without looking at the DB. Maybe the request of Jane took more time to process than the one of John. Which you can solve with transactions but even then, maybe the request of Jane took more time to reach the server and thus the result will be "Pepe" and not "Juan".

The solution you propose against ORMs is pretty common when using ORMs (the pattern I mean) as well and it's simply send the update request for the property that changed regarding the fetched object you already have.

Imagine John and Jane working on the same object at the same time. John updates the customer's Address, and Jane updates the customer's PhoneNo. They both start working on the object at the same time, and have therefor "fetched" the object from the database. John updates the Address field, and clicks "save". Jane updates the PhoneNo field, and clicks "save". Since Jane got her customer object from the "repository" before John saved it, the Address is now reverted back to its old value, the value it had before John updated it. This is referred to as a "race condition". Because the one to save the object last "wins".

Let's convert this following example you shared into something less moronic and more reallistic:

Imagine John and Jane working on the same object at the same time. John updates the customer's Address, and Jane updates the customer's PhoneNo. They both start working on the object at the same time, and have therefor "fetched" the object from the database.
John updates the Address field, and clicks "save". Jane updates the PhoneNo field, and clicks "save".

Since Jane just updated the phone number, the request is only meant to change the phone number, while since John just updated the address so it sends a request to update just the address.

This deals to a better pattern in which you reduce the network traffic, get more specific requests, faster and lighter to process.

No drama, everybody wins, no race conditions affecting different fields on the same schema and the most important, Noting to do with ORMs but on validations.

When you validate an object in the update process you set the values as optional (except of course the primary key). If there's something on any field, validate it with the data type, length and whatever. Then send the update to the ORM.

const customer = {
   Id: id,
   Name: name,
   Address: address,
   PhoneNo: phone,
}

validate against:

const customerSchemaForUpdate = {
   Id: number().min(1).required(),
   Name: string().min(2),
   Address: string().min(3),
   PhoneNo: string.min(9),
}

Update requests get:

const customer = {
   Id: id,
   Address: address,
}
// and
const customer = {
   Id: id,
   PhoneNo: phone,
}

Then the request to the ORM looks like:

// customer = { id: 1, address: 'my Address 64' }
Customer.update( customer, { where: { id: customer.Id } }).catch((error) => console.error('err', error));

and the next req will be

// customer = { id: 1, PhoneNo: '666222787' }
Customer.update( customer, { where: { id: customer.Id } }).catch((error) => console.error('err', error));

Now everything put together:

const customer = req.body; // customer { Id: 1, PhoneNo: '666222787' }

const customerSchemaForUpdate = {
   Id: number().min(1).required(),
   Name: string().min(2),
   Address: string().min(3),
   PhoneNo: string.min(9),
}

const isDataOk = validate(customer, customerSchemaForUpdate) // ok | error

if(isDataOk) await Customer.update( customer, { where: { id: customer.Id } }).catch((error) => console.error('err', error));

And there you go! Both requests can be executed at the same time, asynchronously etc without the issue mentioned in the post and using an ORM, which brings some extra benefits in security and development speed and maintenance.

I do not use OOP in most situations, I just use Objects for convenience hence you can create a new post about using half OOP in those situations and I'll probably agree but it's just that I don't care. I use a multi-paradigm language (JavaScript) so I use the paradigm that's more convenient for each task.

The same way when you read something from a model, you got an object (that's ok) with the fields you actually need, not with everything. e.g. you may not need the created_at, updated_at etc of each register to show movies from Matthew McConaughey on a public view so, why asking for them in the first place?

Having a user without information on optional fields doesn't make the "user" be less "user" and threating required fields (on create) as optional (on update or get) also doesn't harm the overall ORM philosophy.

The only thing I can say generically against ORMs is that If you are a master at SQL, you can probably get more performant queries by writing them yourself.

this is fundamentally incompatible with best practice O/RM design patterns, such as Active Records, Repository Pattern, etc, etc, etc.

In repository pattern, mapping is not the responsibility of the repository. It’s the responsibility of your controllers 🤷🏻‍♀️

It's not the tool (ORM) but how you use it so again, the premise IMO is incorrect, hence it is the conclusion as well.

Hope it bring some light to the topic 😉

Update is a problematic statement and most of us avoid it so the chance of a race like that is pretty rare. This is true regardless of what you use, immutable data is better and much easier to optimize at scale.

Sometimes we do need it though and in this case ORMs handle locking almost seamlessly. No 25% of code or anything really. You can enjoy optimistic or pessimistic locking in ORMs.

About performance. Since caching is the mother of all performance optimizations by giving up on ORM you give up on Level-2 distributed caching. There goes 90% of your performance down the drain when compared to ORM.

I get that you don't like OOP. I disagree but that's subjective. But ORMs can be far superior to the DB on which they are situated. They are much easier to refactor and adapt to new SQL features and can be more performant. That isn't the case with coded SQL.

There are valid cases to be made that the abstraction leads to ignorance and people who don't benchmark the resulting SQL. But that can be said about almost any technology.

I tend to agree with @joelbonetr that this isn't actually about ORMs.

Let's just look at your video which looks at the HTTP requests, and not SQL queries. A decade ago, Google create RequestFactory in GWT, which would make HTTP requests basically looking like yours (much more complex because it models a true object graph, allowing object reuse, reference cycles, etc. and it's not just CRUD, a bit like GraphQL if you squint; anyway) but on the server side it would load the entity, "patch" it, and then save, so it would totally fit with ORMs.

Now let me imagine a different situation: John and Jane make adjustments to "data", and some fields' value depend on other fields (it could just be the traditional cascading dropdowns or similar filters like "this field cannot have this value if that other field has that value"; or it could be more "functional"/business, without hard rules encoded in the software: the user sees the data and adjusts one field based on what it sees on the screen in the other fields). Now if you only "patch" one field at a time, losing the context in which that modification was made, what guarantee do you have that the data still is meaningful? how about validation rules across fields?

Users don't look at the actual data, they look at a snapshot that was fetched moments ago. If their intention is to only modify one field, then sure your solution will work ; if they check each field and fill in others based on that context, then they'd rather either have a lock on the record preventing any modification by another user, or have to deal with "optimistic locking", i.e. "someone made a change to that record since you fetched it", with a conflict resolution screen or whatever (offer to save as-is and have the user look at the audit log to see what had changed and possibly redo the changes)

If you really want to solve the issue of concurrent modifications (while still allowing them), then you'll need changes reflected in real time on the screen, similar to how you can collaborate in a Google Doc or Google Spreadsheet.

"Damn kids, get out of my lawn!"
"Music in my times was better"
I've implemented ORMs before Hibernate and EclipseLink existed. There's .umtiple ways of avoiding updating the whole object or race conditions. You can even have distributed caching in the middle with row versioning for a seamless experience. After over 20 years, I've started making things simpler, most of my microservices are dumb CRUDs. I see your point, but I understand the other side as well. Use whatever you want, and let others use whatever they want... nobody can learn in the head of another.

With today's javascriptization of the dev world (at least web dev), databases are mostly used as a fancy typed document storage with magical querying capabilities. And in document storage you always read everything and write everything. ORMs map pretty well to this.

I'm not saying you are wrong though, just that for many people it might be hard to understand the issue.

ignoring the facts that OOP basically destroyed everything that was good in this world

So subtle 🤣🤣🤣

JSON Patch is a great way to implement partial updates quite easily (and it can be achieved without altering you frontend).

Thx Tamas, I try :)

I have brain damage and I love it, so ORM giving my database brain damage just means it's even easier for me to understand and work with.