You're viewing a comment by Catman and its responses.

Catman Permalink
March 11, 2016, 10:12

Hmm David, I would like to test your apps againt SQL injection. Would be intresting. ORMs are great when it comes to the point of code reading or efficiency. When you avoid ORM you just making your life harder.

Comment Responses

Marco Permalink
March 11, 2016, 10:20

You don't need an ORM to avoid SQL injections. All you need is to encode the query params. And then? That's it.

The advantage of an ORM is *just* to make it look like a bad OOP language. Everybody should know that SQL != OOP. Each technology needs to be used appropriately.

ORM and efficiency should never be used in the same sentence.

Christoph Permalink
March 11, 2016, 10:45

Obviously you never came across the concept of being platform independant..

bro Permalink
March 24, 2016, 13:15

Can you please elaborate, like, how is SQL platform dependent and ORM is not. I don't understand where you are pointing with your sentence.

David Permalink
March 11, 2016, 10:36

I was using an ORM and I learnt SQL just yesterday and now I don't know what all the fuss is about. To defend against SQL injection you only need to call a function. So you have more lines of code, but that's it.

Goliath Permalink
March 16, 2016, 00:46

So basically you copy&paste that line all over your code?

Copy&Paste programming is bad, okay?
You are sure to mess up sooner or later, and if not you, then the maintenance programmer who has to keep your stuff running after you left the company (or the project or whatever).

Boilerplate code is bad, too, okay?
Ideally, each line of your code does something important, and functions and objects abstract away any details below the detail level of your code at that point. That (and a number of other things) makes code readable and maintainable.

At best your extra lines take up monitor space needlessly. At worst they distract from or even drown out what your program really is supposed to do. (IDE code generators are quite like snorting acids up your nostrils to deaden your sense of smell against the stink of boilerplate code.)

Finally, the *correct* way to handle SQL injection is always using place holders in your query (and binding any variable data to them).
Not only is that pattern distinct (and more noticeable when not used), it also allows the DB to compile, cache and optimize the query. That comes handy when you handle larger amounts of queries and data --- i.e. when bad database performance is most noticeable.

So the only defensible answer would be: "I use a single function/method/routine/... that handles all SQL queries and their input data and there all the data is escaped before it enters the query."

bro Permalink
March 24, 2016, 13:07

Wow, you heard of SQL injections. Here is a star, bro. Now, can we continue with productive arguments, please? SQL injection is not a problem inherent to use of SQL as such. It is partially relevant when user is able to compose their own SQL queries, for malicious or other use. Talking in favor of ORM because it eliminates the threat of SQL injection makes you sound like a cool weekend hacker on a weekend hacker conference. All the other hackers will clap and tap you on the shoulder because you namedrop all the cool buzzwords, but a computer scientist will just recall why he went to college instead, where he learned what potential advantages and disadvantages of ORM and SQL are.

"When you avoid ORM you just making your life harder." -- I think what you wanted to say was "When _I_ avoid ORM, I just making my life harder." Don't impose your limitations on others.

Also, read up on ORM mapping problems. I am sure you don't have them, probably because you don't take your underlying data model into account, but some of us do care.

Dave, in all honesty, I think you should accept Catmans proposition -- free test for SQL injections, man, that stuff don't arrive in the offer box every day.

Reply To This Comment

(why do I need your e-mail?)

(Your twitter handle, if you have one.)

Type the word "cdrom_508": (just to make sure you're a human)

Please preview the comment before submitting to make sure it's OK.