Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Geek Culture / [php-mysql] get affect row if already exists?

Author
Message
Phaelax
DBPro Master
22
Years of Service
User Offline
Joined: 16th Apr 2003
Location: Metropia
Posted: 30th Oct 2012 10:24 Edited at: 30th Oct 2012 10:25
When I insert a new row, I can easily get the new row number (its an auto-inc primary key). The issue, however, is what if the row already exists when I try to do the insert? Sure I can do a SELECT before the insert, but I was hoping to reduce it from two external queries.

Here's some basic example code:


ON DUPLICATE KEY UPDATE was new to me, but since I didn't want to change the existing data already there, the insert_id wouldn't update to that current row in question.


[15min later]
And, perhaps posting this now is pointless but I believe I have a working solution and thought I'd share it.

ON DUPLICATE KEY UPDATE `id` = LAST_INSERT_ID(`id`)

Assuming 'id' is the auto-incremented key.

There were some comments here dev.mysql.com stating this still does not work if nothing is updated, but it's working for me. I tested this with MySql 5.0.10

"You're not going crazy. You're going sane in a crazy world!" ~Tick
bitJericho
22
Years of Service
User Offline
Joined: 9th Oct 2002
Location: United States
Posted: 30th Oct 2012 10:50 Edited at: 30th Oct 2012 10:51
you don't set the ID when you insert, you leave that field blank and mysql auto assigns an ID. Then you use last insert ID. If you are doing a new page load and you want to grab the last updated ID, well it could be anything! I'd just use a select inquiry.

Visit my blog http://www.canales.me.
Phaelax
DBPro Master
22
Years of Service
User Offline
Joined: 16th Apr 2003
Location: Metropia
Posted: 30th Oct 2012 14:33
Quote: "you don't set the ID when you insert, you leave that field blank and mysql auto assigns an ID"

That's normally what I do, but for some reason it didn't like me to leave that field out lately so I just went with DEFAULT, which will do the same thing.

Frankly, I'm not even sure why assigning ID in that manner works without it actually changing the value. But it does something internally according to the mysql devs.

"You're not going crazy. You're going sane in a crazy world!" ~Tick
bitJericho
22
Years of Service
User Offline
Joined: 9th Oct 2002
Location: United States
Posted: 30th Oct 2012 14:41 Edited at: 30th Oct 2012 14:42


Have you tried remove `id` from this part? You shouldn't need it, but if you include it you would have to have a value in the next part of the statement.

Also, you maybe shouldn't be using the mysql library in PHP, but rather mysqli at a minimum. I'd even go so far as to recommend using a framework that offers an active record style class, but if you wanna go bare metal mysqli is much safer and harder to mess up.

Visit my blog http://www.canales.me.
Phaelax
DBPro Master
22
Years of Service
User Offline
Joined: 16th Apr 2003
Location: Metropia
Posted: 30th Oct 2012 14:43
Thought I was using mysqli?

"You're not going crazy. You're going sane in a crazy world!" ~Tick
bitJericho
22
Years of Service
User Offline
Joined: 9th Oct 2002
Location: United States
Posted: 30th Oct 2012 15:13 Edited at: 30th Oct 2012 15:15
Ah so you are. My mistake, however, you're not taking advantage of prepared statements, at least in your example. I would write your example like this (untested):




Visit my blog http://www.canales.me.
Phaelax
DBPro Master
22
Years of Service
User Offline
Joined: 16th Apr 2003
Location: Metropia
Posted: 31st Oct 2012 03:12
Haven't dealt with prepared statements before, but I read up on them this morning. I'm writing the code to go along with that method. From what I've read, it seems the major security "risk" that they avoid is injection attacks. But that's not really a security issue to me since I would hope an competent coder would check/validate/escape any data before using it in a query string.

"You're not going crazy. You're going sane in a crazy world!" ~Tick
bitJericho
22
Years of Service
User Offline
Joined: 9th Oct 2002
Location: United States
Posted: 31st Oct 2012 03:27 Edited at: 31st Oct 2012 03:29
Quote: "But that's not really a security issue to me since I would hope an competent coder would check/validate/escape any data before using it in a query string."


Unfortunately it's actually a lot harder to purify data properly and efficiently.

See this link for a quick idea:

http://stackoverflow.com/questions/5139127/php-sql-injection-utf8-poc

They talk about all sorts of things in there and none of which seems like an answer with a "definitively" safe method.

The way I prefer to do it is just use a very public, very popular, often updated ORM. I prefer to do my security via the open source "more eyes, more things fixed" route. That may or may not suit you for a number of perfectly valid reasons. So do what you think is best and always keep in mind that code correctness is only one part of it. Where such things are needed, you can also do active monitoring, firewalling (in the sense of locking down certain parts of your data from being possible to read or edit), and penetration testing.

Visit my blog http://www.canales.me.
Phaelax
DBPro Master
22
Years of Service
User Offline
Joined: 16th Apr 2003
Location: Metropia
Posted: 31st Oct 2012 18:34
I guess it would be harder when the very commands I thought would make my code safe is what's really broken. I always used mysql_real_escape_string rather than add_slashes anyway. But the versions I'm using supposedly have corrected this.

But when binding the parameters, what is it doing differently internally? It's still running the same query with the same data isn't it?

"You're not going crazy. You're going sane in a crazy world!" ~Tick
bitJericho
22
Years of Service
User Offline
Joined: 9th Oct 2002
Location: United States
Posted: 31st Oct 2012 20:59
The idea is that it's impossible for someone to escape a prepared statement. Here's the relevant docs:

http://php.net/manual/en/mysqli.quickstart.prepared-statements.php

They recommend against the prepared statement route unless you'll be repeating statements. But at the bottom it explains the security benefits.

There's always tradeoffs in security.

Visit my blog http://www.canales.me.
Phaelax
DBPro Master
22
Years of Service
User Offline
Joined: 16th Apr 2003
Location: Metropia
Posted: 1st Nov 2012 00:03
Quote: "The idea is that it's impossible"

I've heard that before...

Thanks for the info.

"You're not going crazy. You're going sane in a crazy world!" ~Tick

Login to post a reply

Server time is: 2025-05-17 13:00:53
Your offset time is: 2025-05-17 13:00:53