We were talking about ORM at work today and I was curious. I know ORM was hot several years ago but how many people are still using it? I've had mixed experiences with it and not sure I would use it again unless maybe developing a system from the ground up so I could ensure the app/database was designed with ORM in mind.

ORM is still rather popular in some languages like Ruby (ROR) and Grails (Groovy) but has always had mixed reception in CFML

raises hand as someone who hates all ORMs The problem is that ORMs essentially assume there's a 1:1 mapping between tables in your DB and objects in your model (with leeway for model relationships on top) -- and that often leads to either: databases with really peculiar structures (that may not even be efficient) or object models that are at least one step away from what you actually want. Databases should be viewed as "persistent storage" and you should be able to control the object model to relational model mapping yourself. Unless you are building an absolute CRUD app and your object model and relational model literally are 1:1.

Always hated ORM. Like knitting wearing two catcher's mitts. Never saw the plus, unless you're trying to avoid learning SQL, which isn't a universe I try very hard to think about.

@bdw429s does quick require coldbox? We're using FW/1

@Jim Priest ask in #fw1 but I'm pretty sure some folks have gotten

qb

working with FW/1... I tried to get CB modules/plugins working with FW/1 in general at one point but many of them relied too much on CB features to be easily fooled into working outside of it...

@elpete May know if Quick will work outside of ColdBox.

Unless you are building an absolute CRUD app and your object model and relational model literally are 1:1.

I think a lot of ORM usage starts this way, but the "architects" then go a bit cargo-culty and try to continue the ever-increasingly-square-like peg that is their domain model into the round hole that is ORM.

Quick will not work outside of ColdBox.

I also think a lot of ORM-driven code fails to keep the storage tier out of the way of the domain model, which is kind of its whole point. I have seen apps where all the domain object properties are name as

snake_case

to match the DB columns (!!!), which in turn meant the coding guidelines mandated all variables used snake-case. Which is a complete mishit in a

camelCase

language like CFML. Just... woolly thinking. This is not the fault of the concept of "ORM", but it's a predictable outcome of its misuse.

Back in the day... there were actual object databases (like Poet, etc) and they were great because they didn't try to map objects to relations and tables -- they actually stored objects -- so your object model could be designed "properly" and they were just persistent... magically... Unfortunately, they never caught on (because you could only interact with them via the object model -- so you couldn't attach "standard" reporting tools to your database etc).

Nice. Except a bit of a misfire for them to not also have a SQL-oriented query API.

Back in the '80s, SQL wasn't as ubiquitous as it is today 🙂

Oh right it was that long ago. I guess also back then the idea of compatibility standards between systems was less of a thing. Because "between systems" was less of a thing.

PostgreSQL and MySQL appeared in the mid-'90s -- OODBs had been around since the mid-'80s but died off after the mid-'90s (they were commercial databases and took a dive once solid free, open source RDBs appeared).

Interesting history aside: the old Burroughs computing company was started by William S Burroughs' granddad!

ICL, perhaps?

It was a double-surname name. If you see what I mean. Like "Corfield Cameron" (!!!)

Hewlett-Packard 🙂 (j/k)

Thank-you Sean. No. HA

Sperry Univac?

Am now wondering if it was a NZ manufacturer, and whilst there was some ubiquity in NZ, it wasn't really a thing. I was only a teen in the 80s, so had no functioning brain yet.

I am practically a militant supporter of graph databases. and I like the "theory" of ORMs - but I see them as exactly the same as communism. A completely awesome design in theory - that just doesn't work in the real world. I find SQL is easier to understand, easier to write, easier to debug and ALWAYS faster than ORM operations. I am also a "near" militantly enthusiastic supporter of using a service layer and a gateway/DAO. These "practically" always end up being the service CFC that just calls the DAO of the same-name, with the same arguments... So I add in the use of using the onMissingMethod() in an abstract class that all DAOs extend : to skip having to write the DAO code - which is something I learnt from @markmandel while he was writing ColdSpring. At the time it blew my mind - because I never, previously, considered using "meta" - driven / dynamic programming. Which I am seriously in love with. (where it is understood without too much cognitive load).

I find SQL is easier to understand, easier to write, easier to debug and ALWAYS faster than ORM operations.

There is this too. It oftentimes seems like a solution looking for a problem that doesn't really exist.

You couldn't pay me to use Hibernate ever again. I find Quick to be a lot faster and much more, shall we say, hybrid? In that if I want to just do some SQL I can do that and I'm not locked into the 'THIS IS THE OBJECT RELIGION', and writing up the inevitable 'composite object' cases is really easy. So for me, Quick is just the code we write to deal with objects because we can almost always press a button and 'convert' it to QB/raw SQL.

@sknowlton everyone has their price 🙂

@Jim Priest check this out: https://github.com/tonyjunkes/fw1-quick-example