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]
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)
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.
We were a pretty enthusiastic bunch back in the day. Glad to hear you're still pushing things forward.
> 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.