Escaping variables design

Question

Hi all,
I think this subject has already been handled in this forum, but I've got a few doubt about what's the better way to handle escaping of values when creating SQL commands.
As reported in this treads:
http://forum.java.sun.com/thread.jspa?forumID=48&threadID=586328
http://forum.java.sun.com/thread.jspa?forumID=48&threadID=543270
the use of PreparedStatement against Statement is better for string escaping, but of course you should use the setString method. Now, as I guess many of us, I wrote a database wrapper class that includes a method
public ResultSet query(String sqlString);that provides me results for query in plain SQL strings, such as:
query("SELECT * FROM TABLE1");Of course the problem arises when I've got to pass values in the query, where I should use PreparedStatement. I choose to implement the above code to let the other code do not get dirty with all the same call to create a statement, prepare it and then execute getting the result set. In my head it's cleaner to submit the sql string than to use all around the code the preparedstatement. Moreover I often embed into some objects (e.g., a tree node) the sql query that has generated it, so that the element is able to auto-update itself.
Now it seem I have to rewrite code handling preparedStatement, since my input can include not rightly escaped strings, and I've seen there are other developers that use custom methods to escape fields. So my doubts are: do you think it is better to use preparedStatement everywhere a parametric query happens (most in general everywhere, since code can change one day!) or to prepare a custom method to escape strings and then use the plain sql string? This method could be maybe more efficient for a one shot query, and allows me to store in the object the query that has generated it, while I dind't find a way to convert a preparedStatement (already executed) into its correspondant sql string.
Any clue or documentation to read regard this choice?
Thanks,
Luca

Answer 1

public ResultSet query(String
sqlString);that provides me results for query in plain SQL
strings, such as:
query("SELECT * FROM TABLE1");
I don't know if I like a design like this much, unless this class is used only within a persistence package. By allowing users to pass in SQL, you're forcing them to know about SQL and relational databases. If I want an Order object, I should be able to ask for one without having to know all about the schema and relational details. That's what I want my persistence layer to hide from me. That's what you're not doing.
Of course the problem arises when I've got to pass
values in the query, where I should use
PreparedStatement. I choose to implement the above
code to let the other code do not get dirty with all
the same call to create a statement, prepare it and
then execute getting the result set. In my head it's
cleaner to submit the sql string than to use all
around the code the preparedstatement. Moreover I
often embed into some objects (e.g., a tree node) theWhy a tree node? Something that specific ties you into using a tree. Where's the Order class? You're coupling every layer from front to back this way.
Now it seem I have to rewrite code handling
preparedStatement, since my input can include not
rightly escaped strings, and I've seen there are
other developers that use custom methods to escape
fields. So my doubts are: do you think it is better
to use preparedStatement everywhere a parametric
query happens (most in general everywhere, since code
can change one day!) or to prepare a custom method to
escape strings and then use the plain sql string?There's little object-orientation about any of this.
If you're trying to design a general purpose JDBC framework, you'd do well to look at a good one like that in Spring: http://www.springframework.org
This method could be maybe more efficient for a one
shot query, and allows me to store in the object the
query that has generated it, while I dind't find a
way to convert a preparedStatement (already executed)
into its correspondant sql string.There isn't such a thing, because you bind variables each time.
Any clue or documentation to read regard this choice?Have a look at Spring JDBC. It'll give you some ideas.
I'd recommend that you start thinking about how to layer your application so SQL and relational ideas are restricted to one package.
%