Michael
If I may offer some advice.
The best way is to use PreparedStatement with setString and setInt, that way
you don't have to escape anything.
You can even reuse the prepared statement, this will give a performance
boost.
Be carefull with the locking but I've read somewere that there was already
connection lock,
and then you don't need to worry.
Some example code:
PreparedStatement pstmt = con.prepareStatement("insert into property
values(?,?,?,?,?,?,?)");
pstmt.setString(PROPERTY_URI,uri);
pstmt.setString(PROPERTY_NUMBER,revisionDescriptor.getRevisionNumber());
pstmt.setString(PROPERTY_NAME,property.getName());
pstmt.setString(PROPERTY_VALUE,property.getValue());
pstmt.setString(PROPERTY_NAMESPACE,property.getNamespace());
pstmt.setString(PROPERTY_TYPE,property.getType());
pstmt.setInt(PROPERTY_PROTECTED,protectedProperty);
pstmt.execute();
If you're going to do special character handling maybe you could also look
at
characters like é Small e, acute accent ("é")
I've just tied a proppatch and got the following error:
20 Apr 2001 11:36:00 - INFO - PROPPATCH (time: 31 ms) URI =
/files/draft-fr.xml
org.xml.sax.SAXParseException: End of entity not allowed; an end tag is
missing.
at com.sun.xml.parser.Parser.fatal(Parser.java:2817)
at com.sun.xml.parser.Parser.fatal(Parser.java:2805)
at com.sun.xml.parser.Parser.content(Parser.java:1553)
at com.sun.xml.parser.Parser.maybeElement(Parser.java:1400)
at com.sun.xml.parser.Parser.content(Parser.java:1499)
at com.sun.xml.parser.Parser.maybeElement(Parser.java:1400)
at com.sun.xml.parser.Parser.content(Parser.java:1499)
at com.sun.xml.parser.Parser.maybeElement(Parser.java:1400)
at com.sun.xml.parser.Parser.content(Parser.java:1499)
at com.sun.xml.parser.Parser.maybeElement(Parser.java:1400)
at com.sun.xml.parser.Parser.parseInternal(Parser.java:492)
at com.sun.xml.parser.Parser.parse(Parser.java:284)
at
com.sun.xml.parser.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:95)
at
org.apache.slide.webdav.method.PropPatchMethod.parseRequest(PropPatchMethod.
java:168)
at
org.apache.slide.webdav.method.WebdavMethod.run(WebdavMethod.java:322)
at
org.apache.slide.webdav.WebdavServlet.service(WebdavServlet.java:208)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.apache.tomcat.core.ServletWrapper.doService(ServletWrapper.java:404)
at org.apache.tomcat.core.Handler.service(Handler.java:286)
at
org.apache.tomcat.core.ServletWrapper.service(ServletWrapper.java:372)
at
org.apache.tomcat.core.ContextManager.internalService(ContextManager.java:79
7)
at
org.apache.tomcat.core.ContextManager.service(ContextManager.java:743)
at
org.apache.tomcat.service.http.HttpConnectionHandler.processConnection
HttpConnectionHandler.java:210)
at
org.apache.tomcat.service.TcpWorkerThread.runIt(PoolTcpEndpoint.java:416)
at
org.apache.tomcat.util.ThreadPool$ControlRunnable.run(ThreadPool.java:498)
at java.lang.Thread.run(Thread.java:484)
20 Apr 2001 11:36:00 - WARNING - Bad Request
A fix is really needed, because special characters in property values are
common
in french speaking countries.
Dirk
-----Original Message-----
From: Michael Smith [mailto:[EMAIL PROTECTED]]
Sent: Friday, April 20, 2001 7:37 AM
To: [EMAIL PROTECTED]
Subject: JDBCDescriptorStore and escaping SQL
Hi,
I ran into a problem yesterday where I was adding a property which
happened to have an apostrophe in it. I got a nasty exception because
the apostrophe wasn't escaped.
Before fixing this (well, I have fixed it, but I want to be sure I'm
doing the right thing before committing it), I have a couple of
questions:
Does JDBC give you any methods to do this automatically? (my current
implementation adds an escape() method to JDBCDescriptorStore)
What characters does SQL need escaping? I'm currently just handling '
and \
Which of the above characters are allowed, and where (by slide)? I've
made the assumption for the moment that slide allows them in URIs,
because I don't recall ever seeing anything in slide to disallow them.
As a result, ALL the uris need escaping throughout JDBCDescriptorStore.
It's also probably true that the mysql-specific version of this store
needs the same treatment, and possibly (probably? I don't use it, and
haven't actually looked at it) the JDBContentStore.
Michael
