Discussion on: O/RM is like adding brain damage to your database

[JoelBonetR 🥇]

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 😉

[Thomas Hansen AINIRO.IO]

The solution you propose against ORMs is pretty common when using ORMs as well and it's simply send the update request for the property that changed

It is not very common, it's extremely rare. Most people implement object.Save(), which updates everything.

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 is the correct way to do things, and the way Hyperlambda does it. But it is fundamentally incompatible with ORM libs without violating the entire "philosophy" of how an ORM lib should be used. Most who actually do implement it, implements it by retrieving the object, applying the changes, and (sigh!) invokes updatedObject.Save(). I don't even need to tell you why that's bad I presume ...

Noting to do with ORMs but on validations

There doesn't exists a single ORM that implements this. Because it is a violation of the "Design Patterns" ORMs' are built on. Don't get me wrong, some ORMs do implement this, but the devs using this feature of ORMs are no longer using their ORM as an ORM, but rather as "something else". Regardless, once you start using your ORM like this, you've got no use for your ORM, and you might as well throw it out. EF, the most popular ORM for .Net had existed for more than a decade before they even implemented the ability to do this ...

Then the request to the ORM looks like:

Your code is fundamentally incompatible with OOP. If you're using such code, you're not using OOP, and you're not using ORM, since the latter implies an OOP model ...

Hope it bring some light to the topic 😉

[JoelBonetR 🥇]

It is not very common, it's extremely rare. Most people implement object.Save(), which updates everything. ... it is fundamentally incompatible with ORM libs without violating the entire "philosophy" of how an ORM lib should be used. Most who actually do implement it, implements it by retrieving the object, applying the changes, and (sigh!) invokes updatedObject.Save(). I don't even need to tell you why that's bad I presume ...

We may have very different experience on projects, languages, tools and overall but only saw this on a couple of "dinosaur" projects in which they handled those things on various abstractions (non-sense) and sometimes even wrong.

I've always worked like that explained on the comment above for reasons I feel obvious.

Your code is fundamentally incompatible with OOP. If you're using such code, you're not using OOP, and you're not using ORM, since the latter implies an OOP model

As far as I'm concerned I don't use classes in JS, just Objects (as everything is an Object and the Object Object itself is a convenient data structure to use) and also don't think there's a single thing to rule them all so If some thing needs a paradigm for any reason good! go for it but I won't stick to a single thing.

I may need to take a think on that to see why is it incompatible with OOP.
AFAIK there are optional props in most languages that implement OOP, i.e.

class State {
   private Integer something; 

   public Optional<Integer> getSomething(){
      return Optional.ofNullable(something);
   }
} 

Maybe @codenameone can bring some light here as I'm not using Java since some years ago.

At first glance I think those are different topics, on one side we have Object Mapping (to a model) and on the other side we have object property propagation (how many of those properties you need to propagate and/or use on each place).

[Shai Almog]

I don't see any way in which this is incompatible with OOP. SQL itself isn't OOP and we use ORMs to bridge the gap. They aren't ideal OOP and one of the big mistakes people make with such tools is to build them as if they are (excessive inheritance in object model, etc.).

There's no need to be religious about OOP or functional programming. Each has its strengths and we each find the balance in the languages best suited for the job.

I'm good with null personally even though we have Optional. That maps directly to the way the DB stores the data.

Save doesn't update everything in tools like hibernate. It instruments the object and knows the specific fields we set. You don't need any optional or anything for this to work seamlessly. It generates relatively long and verbose queries but they are more efficient as a result.

[Thomas Hansen AINIRO.IO]

As far as I'm concerned I don't use classes in JS, just Objects (as everything is an Object and the Object Object itself is a convenient data structure to use)

Bingo; ORM is an OOP pattern. No OOP, no ORM. JavaScript is not OOP. You're not using an ORM, you never have been using an ORM, and assuming you don't start typing in a strict typed programming language any time soon, you probably never will use an ORM either - What you're doing is using the good parts from JavaScript to circumvent the problem of optimistic/pessimistic database locks ...

[JoelBonetR 🥇]

I took the sentence of ORM being an OOP pattern as true at first sight but something was crackling in my head.

Take that definition instead: ORM is a programming technique for converting data between incompatible type systems in relational databases and objects in programming languages. This creates, in effect, a "virtual object database" that can be used from within the programming language.

You have a RDB with it's types and it's tuples and so on, you create Objects with properties that map those.
As long as the programming language accepts Objects it does not need to live in an object-oriented implementation, and even objects didn't exist you could use any data structure to replicate the same.

Also nothing to do with strict typed programming languages; a varchar(180) will never map to a programming language type, that's why you add validations and logic in between, to tackle certain security concerns and ensure your data is consistent in the DB and to prevent errors or your data being cut down when trying to store it.

String property; // just maps to "String" type, regardless of the length
Char myProp; // can also be stored in a varchar or text DB type, but is not the same than String

I get my Model mapped to Objects, hence the Object-Relation Mapping is fulfilled. So yes, I'm using an ORM.

[Thomas Hansen AINIRO.IO]

O in ORM implies “Objects”, as in strongly and strict typed OOP. No strict types, no ORM. Many will disagree with me here, but ORM is fundamentally a design pattern for OOP languages. No (strictly typed) OOP, no ORM …

You’re using something else. Don’t believe me, check out the Java guy commenting here … 😉

[JoelBonetR 🥇]

If you invent something like Array Oriented Programming and ArrayHandlers instead classes, while adding functions to Array indexes instead methods it will not make Array exclusive of this weird thingy.

• Objects are not exclusive of OOP.
• OOP does not require strict typing, those are different concepts.
• An ORM also does not need that you implement everything in OOP, the implementation details of the ORM will use OOP themselves.
• There are FRM as well as ORM, the purpose is -allegedly- similar but the implementation is -obviously- different, as SQL is a declarative language itself you don't get as many benefits as you do with ORMs. It has more sense to use ORM than FRM -usually- even when dealing with FP implementations.

If I'm using JavaScript (imagine I don't use TS) and without implementing OOP as paradigm for everything will not make my ORM be less ORM. The OOP implementation is in the ORM itself and I don't need to follow the same, I just need to use what it provides.

[Thomas Hansen AINIRO.IO]

about Array programming languages? It's already been with ys for 6 decades. It's called Lisp 😉

You're using the "good parts" from JS. JS is not OOP. I'll probably have 95% of the workd disagreeing with me here, but the truth is the truth regardless of how many who argue against it ...

[JoelBonetR 🥇]

JS is a multi-paradigm language, and OOP fits inside this "multi". It not being "Pure" doesn't mean it's not capable of handling OOP. Neither you need Pure OO to provide an ORM.
Also Lisp has the code represented as linked lists that does not mean is array oriented.

[Thomas Hansen AINIRO.IO]

Bring it up with Martin Fowler 😉

[JoelBonetR 🥇]

Maybe you should ask Alan Kay instead, don't you feel it more appropriate?

“OOP to me means only messaging, local retention and protection and hiding of state-process, and extreme late-binding of all things.” ~ Alan Kay

😉

[Thomas Hansen AINIRO.IO]

I agree. Unfortunately 99% of the world still believe OOP is equivalent with C++ and Java ... 😕

I built Hyperlambda by drawing inspiration from Lisp and Alan Kay in fact. You should watch Alan Kay's speech at OOPSLA 97 BTW ...

[JoelBonetR 🥇]

Unfortunately 99% of the world still believe OOP is equivalent with C++ and Java

By the rest of the post and comments, you seem to be in this 99% isn't it?

Again those are different concepts.

On one side there is OOP (a programming paradigm) and on the other side we have programming language implementations which can be more or less accurate to fulfill the paradigm and can or cannot be a re-interpretation of the original paradigm.

I'm not picky with this things, as far as I'm concerned, if Java and C++ did an OOP implementation that's not aligned with the original idea of OOP the people behind that should have good reasons to proceed that way (and they had in fact).

You should watch Alan Kay's speech at OOPSLA 97 BTW

I'll search that in youtube and save it for later 😁 can't recall if I watched it but even if I did it was long time ago.

[Thomas Hansen AINIRO.IO]

His main thesis is that we ate still in the stoneage. The name is "The computer revolution has not happened yet" ... 😉

[JoelBonetR 🥇]

Well there's always iterations.
Look at the ML niche, analog computers are getting stronger on that field of study for good reasons.