[ssmoot]

You nailed it. HABTM just never worked, and there was little interest in making it work. Since I handed out commit-access like candy, the majority of contributions were to endlessly refactor. Or do things like letting you treat a CSV file as a database. And HABTM still didn't work.

I didn't know how to put the genie back in the bottle. I didn't have the same problems that prompted me to create DM in the first place anymore (and by that point, I wasn't sure that porting a large Java Pattern to Ruby was even a good idea considering what I'd learned in the process about method dispatch performance in Ruby) and I was burned out on maintenance. So I handed over the keys and the rest is history.

I messed up. :-)

Today I'm happily writing apps with akka-http and think O/R Mappers are a fundamentally flawed idea. It's like trying to build a truck to move a few yards of dirt 100 feet. It'll never pay off. And I think even "users" would probably find that the hours they put into learning and using the tool will never get ahead of the performance, simplicity and linear scaling of effort they'd have had with a simpler solution.

So these days I'm much more likely to write this in Scala:

  val limit = 10.0

  sql"SELECT name FROM coffees WHERE price < $limit".as[String]

Than anything else. You will never find an O/RM that's faster, simpler or easier to write and maintain than that.

Plus Contextual Validations in the O/RM is just a bad idea. Even if they do appear in the PoEAA. First-class-Form objects and deserialization/validation at the app boundaries may not be a new idea, but it's the right one. (IMO)

[solnic]

Hey Sam, great to see you commenting on this :) I started contributing to DM when Dan was already in charge but I was a DM user when you were still working on it.

Anyhow, you made really good points here. I've worked on ORMs for a couple of years before I concluded the same - NOT WORTH THE EFFORT.

My approach with rom-rb is functional, as in this project works more like persistence libs in functional languages, rather than an O/R mapper. I removed the whole idea of mutable objects and managing their state using UoW etc. This simplified the stack a lot, and despite a complete lack of any performance-related tweaks rom-rb is already faster than ActiveRecord.

I also agree with your opinion re validations. I removed this concept from rom-rb as well and built a standalone validation library instead. This works very well.

Cheers!

[ssmoot]

I think I'd blocked out the pain of dealing with mutable strings. :-)

We were a pretty enthusiastic bunch back in the day. Glad to hear you're still pushing things forward.

[vinceguidry]

That sounds like the pain I went through when I tried to write my own ORM. You want to go nuts with refactoring, chasing an ideal design that just doesn't exist.

> So these days I'm much more likely to write this in Scala:

I do this sort of thing a lot in ActiveRecord. I'll write a class method with ".where('price is null or price < ?', argument)". I use ActiveRecord a lot like I use Sequel, drilling into the underlying database layer. It occasionally bites me, but when it does, it's a good reminder to simplify my database architecture while nothing else is relying on it.

This way I can get the benefits of an object that behaves the way I want it to behave, but also respects the data layer. I don't want to give up either.

I do feel like Rails, in an effort to make things easy, encourages devs to overcomplicate their apps.