161–170 of 305 posts
I've always said: "ORMs are for people who don't know SQL!"
More to your point, I think the problem is the vast number of developers using ORMs without knowing SQL and running into big problems with correctness and performance.
Earlier quoted context omitted.
Deciding between user or not is the most simple case though. The most monstrous function I have by far considers things such as - is the user logged in, and maybe even owner of the profile we're at? - are we looking at all nodes, or the subnodes/subtree (don't ask) of a node? - do we want to display tags/authors/sources? - are we filtering by tag/author? - what's the display mode: list or full? There might be more to…
This actually feels a lot like localization -- unrolling all the ifs is actually the best way to do it. It feels like you're repeating yourself, but having the whole sentence / query together as one unit gives you the ability to understand the whole context -- often times in a database context, you can omit parts that are useless if you get the full context.
But as I said in my other comment, I realized I can just remember the parameters/values as I build the query string, and then bind them all after creating the query. That way I can have my messy cake (that should feel so wrong but tastes so right) and eat it with a plate and a fork like a proper person.
Earlier quoted context omitted.
You can write well written modular SQL that supports changes and can be read by a competent developer.
Not in my experience. Please show me actual examples of "well-written modular SQL" in a real application.
I like to encapsulate inside of stored procedures, and write my code in such a way that it reads almost like a a procedural language. Heavy use of indentation, subqueries, and temp tables lets you carry results through the proc. I like to hang conditions off of joins, so related logic is in the same place.
Pretty much every other ORM I've worked with has been terrible by comparison.
Earlier quoted context omitted.
The Persistent library is an ORM. It provides syntax and safety for sql. For example delete $ from $ \t -> do where_ $ (t ^. TutorialAuthor) ==. (sub_select $ from $ \a -> do where_ (a ^. AuthorEmail ==. val "anne@example.com") return (a ^. AuthorId)){-/hi-} tuts do where_ (t ^. TutorialSchool !=. val True) return (t ^. TutorialTitle) looks a lot like something you might get with a good ORM. It might be more general…
Haskell doesn't have OO, so it can hardly be an ORM. The library in question is modeling relational theory at the language/type level. That's not remotely like an ORM.
That said, persistent doesn't do OO.
Earlier quoted context omitted.
> If you're not using an ORM, then you ultimately end up writing one. I disagree with this. A lot of things people use ORMs for are rather easily solved with stored procedures, especially in Postgres where you can write stored procedures in Perl, Ruby, etc. Validations, “fat models”, etc are all managed with SQL easily (and this means you get that functionality from _anywhere you access the database_, not just from y…
One problem with the stored procedure approach is that it scales terribly. If your logic is in app servers and your state in a DB, you can add more app servers, and it will be a long time until your DB get overwhelmed. When your DB is doing both , the choking point is much earlier.
Not this again. Why is this coming up at all in 2016? There isn't even a valid debate here. ORMs are a tool, that's it. The relational operations of SQL and the object-oriented (or functional) logic of your application code are usually very different and it's nice to have a mapper that lets you interact with your app's language while it takes cares of automatically mapping it to SQL. For 99% of database ops where it'…
My experience with hibernate, entity framework, nhibernate, and lastly dapper has basically left me thinking Dapper is all you'll ever want. I can't imagine a use case where I'd rather opt for NHibernate or EF at the moment. (I might add, Dapper in combination with C#6 even gives me enough type saftey to be happy. String interpolation and the nameof operator complements dappers DTO approach nicely) Since you seem to…
Earlier quoted context omitted.
> If you're not using an ORM, then you ultimately end up writing one. I disagree with this. A lot of things people use ORMs for are rather easily solved with stored procedures, especially in Postgres where you can write stored procedures in Perl, Ruby, etc. Validations, “fat models”, etc are all managed with SQL easily (and this means you get that functionality from _anywhere you access the database_, not just from y…
One problem with the stored procedure approach is that it scales terribly. If your logic is in app servers and your state in a DB, you can add more app servers, and it will be a long time until your DB get overwhelmed. When your DB is doing both , the choking point is much earlier.