in reply to DBI: table locking
This is not the best solution. The best solution would be either PostGreSQL, or getting transactions to work in MySQL. But given where I'm up to with the project I'm working on I'm going to have to live with the second-bestness of it. A bit of a sledgehammer to crack a nut... but it DOES crack the nut!$dbh->do("LOCK TABLES tbl WRITE"); $dbh->do("INSERT INTO tbl VALUES(NULL,'foo','bar')"); my $ref = $dbh->selectcol_arrayref(" SELECT LAST_INSERT_ID() FROM tbl"); $dbh->do("UNLOCK TABLES");
So, each instance of your script will have its own database handle, and will only do one INSERT, so the 'mysql_insertid' will be the right one. There is no chance of the insertid being that of a subsequent INSERT that a different process performed (you're not sharing the handle, mysql will not fuck up in this manner).DATABASE HANDLES The DBD::mysql driver supports the following attributes of database ha +ndles (read only): $infoString = $dbh->{'info'}; $threadId = $dbh->{'thread_id'}; $insertId = $dbh->{'mysql_insertid'} These correspond to mysql_info(), mysql_thread_id() and mysql_insertid +(), respectively. insertid MySQL has the ability to choose unique key values automatically. If th +is happened, the new ID will be stored in this attribute. This attrib +u +te is not valid for DBD::mSQL. An alternative way for accessing this +a +ttribute is via $dbh->{'mysql_insertid'}. (Note we are using the $dbh + +in this case!)
|
|---|