Community
Participate
Working Groups
Build ID: I20080617-2000 (CDO, Net4j = CVS HEAD) Steps To Reproduce: // using MySQL DB-Store (native, not hibernate!) @Test public void testStoreStringBackslash() { CDOResource resource = transaction.getOrCreateResource("/test"); Company e =Model1Factory.eINSTANCE.createCompany(); e.setName("foobar\\"); // this escapes only the string! // resulting string only contains one backslash resource.getContents().add(e); transaction.commit(); } More information: results in I did not check about other Databases (Derby, HSQLDB). However, this leads to DBType.appendValue to generate '... foobar\' which seems incompatible with MySQL query.
Seems to work in HSQLDB - attached TestCase. http://www.jguru.com/faq/view.jsp?EID=8881 says: ---- SELECT * FROM BIRDS WHERE SPECIES='Williamson's Sapsucker' In this case, the apostrophe in "Williamson's" is going to cause a problem for the database because SQL will interpret it as a string delimiter. It is not good enough to use the C-style escape \', because that substitution would be made by the Java compiler before the string is sent to the database. Different flavors of SQL provide different methods to deal with this situation. JDBC abstracts these methods and provides a solution that works for all databases. With JDBC you could write the SQL as follows: Statement statement = // obtain reference to a Statement statement.executeQuery( "SELECT * FROM BIRDS WHERE SPECIES='Williamson/'s Sapsucker' {escape '/'}"); The clause in curly braces, namely {escape '/'}, is special syntax used to inform JDBC drivers what character the programmer has chosen as an escape character. The forward slash used as the SQL escape has no special meaning to the Java compiler; this escape sequence is interpreted by the JDBC driver and translated into database-specific SQL before the SQL command is issued to the database. ---- Will try with MySQL on Monday, maybe it's a good idea to use the JDBC escape notation as cited above.
Created attachment 118543 [details] TestCase TestCase for string storing issues.
Created attachment 118657 [details] Testcase + Patch - Testcase from previous patch is included - Moved string escaping logic to DBAdapter -> Now runs with all three database backends.
Stefan Can you please resolve the merge conflicts against HEAD (test case)...
Created attachment 118990 [details] Resynced prev. patch w/ HEAD
Created attachment 119026 [details] Patch v4 - ready to be committed My only concern is that the appendValue method looks very similar in all concrete DBAdapters. Cold that be abstracted somehow? I leave it up to you...
Committed to HEAD. I see the argument of abstracting the common code. But then again, I don't know which special cases will pop up in the future for single databases. This way the code stays more changeable for single databases and we can react to special cases more efficiently.
Agreed ;-)
Fix available in CDO 2.0.0M4
Generally available.
