Skip to main content
Ben Nadel at Scotch On The Rocks (SOTR) 2011 (Edinburgh) with: Hugo Sombreireiro
Ben Nadel at Scotch On The Rocks (SOTR) 2011 (Edinburgh) with: Hugo Sombreireiro@hsombreireiro )

Ian Turton

Member since Jun 18, 2022

Recent Blog Comments By Ian Turton

  • It's OK To Be Super Explicit In Your Data Access Method Names

    Posted on Jun 20, 2022 at 12:28 PM

    @Ben, Yes! ...and the reason you're not getting it from the docs (IMO) is they've gone straight to a slightly obfuscatory, non-obvious example. Whereas way back when I found VALUES() I came to it from a 'there must be a way for me to stop repeating all these params cos it's dangerous/ted... read more »

  • It's OK To Be Super Explicit In Your Data Access Method Names

    Posted on Jun 20, 2022 at 12:07 PM

    @Ben, I reckon the disconnect here is you think I'm trying to 'improve' your final query, the one that gets the id in the event that the upserts ends up being an update. I'm not - it's about the first upsert I'm trying to fix the issue that, using your original upsert example, you have to ... read more »

  • It's OK To Be Super Explicit In Your Data Access Method Names

    Posted on Jun 18, 2022 at 11:06 AM

    @Ben, you can use the VALUES(col_name) function to refer to column values from the INSERT portion That's it right there. I don't know why they've gone immediately to an example of a non-obvious use for this (e.g. the single insert version of your statement I posted), but I suspect t... read more »

  • It's OK To Be Super Explicit In Your Data Access Method Names

    Posted on Jun 18, 2022 at 9:36 AM

    Assuming this is MySQL, I prefer to use the VALUES function on the update part. Apart from being more readable, it removes the possibility that I make a change to the insert part and forget to change the update (or vice versa) so e.g. ON DUPLICATE KEY UPDATE valueOne = VALUES(valueO... read more »