2014-10-06 19:01 GMT+02:00 Alok Menghrajani <[email protected]>: > Hello, > > On Mon, Oct 6, 2014 at 4:12 AM, Lukas Eder <[email protected]> wrote: > > Here's a little feedback. While I understand that this is an annoying > issue > > to MySQL users, I do think that in the long run, backslash escaping > should > > be avoided in MySQL for database interoperability reasons. I trust that > > MySQL is going to start enforcing a stricter SQL standards compatibility > in > > the future - this was also Oracle's official position mentioned at the > > Oracle Open World conference. I will be blogging about this pretty soon. > > I agree MySQL should get their act together and stick to the standard. > A coworker however brought up a concern. Given that MySQL's default > behavior is to escape backslashes, he thinks not escaping backslashes > might be less tested and have issues. For example, he pointed me to: > > http://bazaar.launchpad.net/~mysql/connectorj/5.1/view/head:/src/com/mysql/jdbc/PreparedStatement.java#L4781 > > I don't have enough context to tell how much of an issue this is going > to be, but it's something to keep in mind. >
Ugh. Nice discovery! I'll check back again with Morgan and Jess about this. This looks like a problem to me. Also, Morgan has pointed out an interesting aspect about the NO_BACKSLASH_ESCAPES property with respect to backwards-compatibility, when I asked him if it could be included in MySQL 5.7's new STRICT mode: http://www.tocker.ca/2014/01/14/making-strict-sql_mode-the-default.html#comment-1621690667 In any case, I guess this escaping will stick around for another while, and if jOOQ can abstract it entirely, that would be a great value proposition for jOOQ/MySQL users, also in terms of security. > For the time being, this is a real issue, of course, and we'll implement > > #3000 eventually, which allows for alternative string escaping modes: > > https://github.com/jOOQ/jOOQ/issues/3000 > > :) > > > I prefer this not to be strictly tied to backslash escaping, as other > > databases (such as PostgreSQL) may implement additional means of > escaping. > > Do you want a pull request to support PostgreSQL's escaping? > Let's first discuss how this could be implemented. It's not a priority though, so if you don't have an immediate stake, I'd prefer not to include it in jOOQ 3.5.0 anymore. > > Also, I don't think that any interaction with the Connection setting is a > > good idea, in particular when tampering with such settings. I believe > that > > the suggestion involving calls to "SET @@SESSION.sql_mode..." originates > > from a local use-case, and it will probably break in more general > contexts, > > e.g. in setups that other users may have. > > Agree. I was going for something that would be fool-proof and do the > safe thing by default. We can revisit this in the future. > > Thanks for fixing this! We certainly should. I really wonder if there is any way through standard JDBC API to access the NO_BACKSLASH_ESCAPES property. I haven't found it in Connection.getClientInfo(), nor in INFORMATION_SCHEMA.SESSION_VARIABLES... I also don't find it in @@SESSION.sql_mode -- You received this message because you are subscribed to the Google Groups "jOOQ User Group" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
