Hi Anthony, > I can't imagine > anyone wanting to introduce races or hammers into a library that's used in > any production environment, even if it does present warnings/disclaimers > regarding the less than ideal behaviour.
That's not the problem. The simulation of some SQL clauses and/or statement is always a bit of a kludge. I frequently blog about these things. For instance: Simulation of pessimistic locking in SQL Server / CUBRID: http://blog.jooq.org/2012/05/18/for-update-simulation-in-sql-server-and-cubrid/ Bitwise operations (e.g. [a << b] is the same as [a * power(2, b)] which is the same as [a * exp(ln(2) * b], if you don't even have the power() function): http://blog.jooq.org/2011/10/30/the-comprehensive-sql-bitwise-operations-compatibility-list/ Some string operations in SQLite (e.g. [ rpad('abc', 7, '-') ] being the same as [ 'abc' || replace(replace(substr(quote(zeroblob(4)), 3, 4), '''', ''), '0','-') ]: http://blog.jooq.org/2012/07/19/funky-string-function-simulation-in-sqlite/ > Failing such an ingenious proposal, I'll keep our workaround application > specific. Well, you could still give it a shot to simulate MERGE for other databases. I'm sure this would help quite a few jOOQ users. If someone finds a more reliable way, they can patch / fix your solution. > I would prefer to be able to just override this particular operation rather > than maintain a fork of jOOQ with a patched MySQL-specific mergeInto. You essentially have two options: - provide a working pull request for the org.jooq.impl.MergeImpl class - implement your own org.jooq.Query, which delegates to jOOQ's MERGE statement for those databases that support it, or to a custom implementation for MySQL. Cheers Lukas
