Hi Lukas and all, I'm considering implementing simulated support for mergeInto for MySQL, but before I do, I thought it'd be a good to run the idea past you to see if it's already been tried before and if so, what issues held it back.
First, I should explain why the onDuplicateKeyUpdate feature isn't sufficient for our needs. Very simple: the unique key that we need to use isn't the primary key. Without this feature, I'll be taking a less robust but quite straightforward approach to our problem. * Try to insert * when unique key constraint violation, try to update * Raise/throw exception if no rows updated (another transaction deleted the record between insert and update) For our use, that behaviour is acceptable, since the only scenario involves a user who can retry the operation (also very low chance of occurrence). Of course, the obvious alternative - reversing the order - has a similar lack of robustness, in that a conflicting record could be inserted between the update and the insert. I believe that the only locking that could completely avoid the race conditions would be a table lock, which I expect wouldn't be acceptable in the MySQL implementation of mergeInto. What are your thoughts on whether I should proceed with trying to integrate some support for mergeInto for MySQL into jOOQ, or just leave it as an application-specific operation? Cheers, Anthony P.S. amazing project - not just the library, but also your responsiveness, website, docs, and everything else
