Any system I've worked in that didn't use an ORM still implements an ORM.
Save methods which runs insert or updates. GetAll methods get_by_username, get_by_id, get_by_email, get_recent, get_by_foreign_keyed_object, get_by_other_foreign_keyed_object.
And all those hand coded methods directly tied to the dialect of the db the original developer used.
Using Hibernate I had to write raw SQL for some reporting. I've never written raw SQL in Django (the project I've used django on self select for simplicity).
And using SqlAlchemy/Twisted as a backend for a desktop application I haven't found a need yet, for performance or correctness. I have one query I'm eyeing for an SQL rewrite, but it'll probably be a week of work to make sure it works correctly and I'd rather release this phase than save 30 seconds on a weekly query.
I've reached a point where ORM complaints don't really make all that much sense. The issue seems to be "THe ORM breaks down doing X and Y and Z so I had to hand write SQL!"
But you'd be writing X Y and Z anyway if you weren't using an ORM, so what's the issue?
Exactly. Or more explicitly, the anti-ORM argument, to me, consists of: ORM works fine for A through W, but SQL is better for X, Y, Z. So rather than just the common sense solution of writing just X,Y,Z in raw SQL, everything has to be written in raw SQL.
The argument works both ways; in fact, I think it's worse the other direction. Most projects use the ORM and just the ORM and it's against policy to write anything in raw SQL even if it's better for X, Y, Z.
The attitude is prevalent in the design of many ORMs. I'm both a huge advocate of ORMs and of SQL. A good ORM provides a simple and direct mapping from storage to the object model. But most ORMs go beyond that and try to cover all the query and performance possibilities available from SQL. Some ORMs have their own text-based query language!
I've met developers who can happily (and effectively) work with an ORM but hardly even know SQL! They certainly don't know SQL well enough to use it in the situations were it would be most effective.
I'm starting to feel like really effective set-based understanding of SQL is becoming sort of a lost art.
Any system I've worked with that didn't use SQL directly ended up implementing poorly a system for describing sets of data. SQL isn't a perfect implementation of relational algebra but it's better than a bunch of nested loops.
Save methods which runs insert or updates. GetAll methods get_by_username, get_by_id, get_by_email, get_recent, get_by_foreign_keyed_object, get_by_other_foreign_keyed_object.
And all those hand coded methods directly tied to the dialect of the db the original developer used.
Using Hibernate I had to write raw SQL for some reporting. I've never written raw SQL in Django (the project I've used django on self select for simplicity).
And using SqlAlchemy/Twisted as a backend for a desktop application I haven't found a need yet, for performance or correctness. I have one query I'm eyeing for an SQL rewrite, but it'll probably be a week of work to make sure it works correctly and I'd rather release this phase than save 30 seconds on a weekly query.
I've reached a point where ORM complaints don't really make all that much sense. The issue seems to be "THe ORM breaks down doing X and Y and Z so I had to hand write SQL!"
But you'd be writing X Y and Z anyway if you weren't using an ORM, so what's the issue?