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

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