Beefy Boxes and Bandwidth Generously Provided by pair Networks
The stupid question is the question not asked
 
PerlMonks  

Re: SELECT LAST_INSERT_ID does not work

by chacham (Prior)
on Jun 28, 2017 at 20:37 UTC ( #1193789=note: print w/replies, xml ) Need Help??


in reply to SELECT LAST_INSERT_ID does not work

As others have pointed out, this is a per-connection function, so if there are multiple clients, that may be affecting it. Also, triggers or the like that grab a new id (even if left unused) may b affecting it.

One kludge, perhaps, to guarantee it to work, would be to use a stored procedure to do the insert, run the select, and return the result from the select to you.

  • Comment on Re: SELECT LAST_INSERT_ID does not work

Replies are listed 'Best First'.
Re^2: SELECT LAST_INSERT_ID does not work
by afoken (Canon) on Jun 29, 2017 at 04:17 UTC
    Also, triggers or the like that grab a new id (even if left unused) may b affecting it. One kludge, perhaps, to guarantee it to work, would be to use a stored procedure to do the insert, run the select, and return the result from the select to you.

    If a trigger modifies the data for LAST_INSERT_ID, how could a stored procedure executing INSERT and SELECT LAST_INSERT_ID() guarantee that the data is not overwritten?

    Alexander

    --
    Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

      It cannot guarantee it was not overwritten, but it can guarantee what was inserted by that statement.

      If a trigger runs as a result of the select, the insert will not finish until the trigger is finished, so the next statement should be accurate. (I am assuming noone is trying to specifically avoid detection with some fancy logic in the trigger.)

        My problem with LAST_INSERT_ID is that it is not well-defined. https://dev.mysql.com/doc/refman/5.7/en/getting-unique-id.html starts with a definiton and links to more information:

        For LAST_INSERT_ID(), the most recently generated ID is maintained in the server on a per-connection basis. It is not changed by another client. It is not even changed if you update another AUTO_INCREMENT column with a nonmagic value (that is, a value that is not NULL and not 0). Using LAST_INSERT_ID() and AUTO_INCREMENT columns simultaneously from multiple clients is perfectly valid. Each client will receive the last inserted ID for the last statement that client executed.

        So far, so good. We don't have to worry about parallel access from different clients, that piece of data is stored per connection. Inserting values different from NULL and 0 into an AUTO_INCREMENT column does not change the data. That may be a little bit surprising, but it should be easy to handle. And we get the last generated ID.

        Linked from there, we can find https://dev.mysql.com/doc/refman/5.7/en/information-functions.html#function_last-insert-id. Unfortunately, it documents a significantly different behaviour:

        With no argument, LAST_INSERT_ID() returns a BIGINT UNSIGNED (64-bit) value representing the first automatically generated value successfully inserted for an AUTO_INCREMENT column as a result of the most recently executed INSERT statement.

        And this is even repeated in an "Important" block:

        If you insert multiple rows using a single INSERT statement, LAST_INSERT_ID() returns the value generated for the first inserted row only. The reason for this is to make it possible to reproduce easily the same INSERT statement against some other server.

        We get the first generated ID for an INSERT statement, not the last one. Wouldn't it be nice to have a documentation that does not contradict itself?

        Also documented there:

        The effect of a stored routine or trigger upon the value of LAST_INSERT_ID() that is seen by following statements depends on the kind of routine:

        • If a stored procedure executes statements that change the value of LAST_INSERT_ID(), the changed value is seen by statements that follow the procedure call.
        • For stored functions and triggers that change the value, the value is restored when the function or trigger ends, so following statements will not see a changed value.

        So changes to the last ID value are persistent from stored procedures, but not from stored functions and triggers.

        https://dev.mysql.com/doc/refman/5.7/en/mysql-insert-id.html, linked from the first document, documents once again that the first ID is stored, not the last one:

        In the case of a multiple-row INSERT statement, mysql_insert_id() returns the first automatically generated AUTO_INCREMENT value that was successfully inserted.

        But only a few lines later, the something very different is documented:

        The return value varies depending on the statement used. When called after an INSERT statement:

        If there is an AUTO_INCREMENT column in the table, and there were some explicit values for this column that were successfully inserted into the table, return the last of the explicit values.

        When called after an INSERT ... ON DUPLICATE KEY UPDATE statement:

        If there is an AUTO_INCREMENT column in the table and there were some explicit successfully inserted values or some updated values, return the last of the inserted or updated values.

        So the last-insert-id value is overwritten by explicit values, according to that page.

        I originally wanted to read the two other pages linked from the first document, but I'm getting sick of MySQL.


        Just for fun, let's have a look at PostgreSQL:

        PostgreSQL has the pseudo-types SERIAL and BIGSERIAL that really are INTEGER and BIGINT, combined with an implicit NOT NULL constraint and a DEFAULT clause referencing to an automatically created sequence: https://www.postgresql.org/docs/9.1/static/datatype-numeric.html#DATATYPE-SERIAL (This is a link to an older 9.x series documentation, but I know that mechanism is available since at least the 8.x series).

        Getting the last inserted value is easy: Either explicitly query the sequence for the current value inside a transaction, or even shorter, use the extended INSERT syntax INSERT INTO table .... RETURNING idcolumn, as documented in https://www.postgresql.org/docs/9.1/static/sql-insert.html.

        DBD::Pg implements last_insert_id() by querying the database for the sequence name and its current value.

        The INSERT ... RETURNING way is unfortunately not portable, but it is the cleanest aproach to return an automatically generated ID that I know.


        A quick look at Oracle. The documentation for last_insert_id in DBD::Oracle is very clear: Oracle does not have anything like SERIAL or AUTO_INCREMENT. You need to manually use a sequence. You can read the sequence value from within the INSERT statement, and, similar to PostgreSQL, you can extend the INSERT statement to return the inserted value (using RETURNING). An other way to implement an automatic IDs is to create a trigger on the table that overwrites the ID column with a sequence value. This was the way that I learned while learning to use Oracle. Later, I wrote (perl) code to first fetch the next value from a sequence, then use that value for an INSERT statement. That way, I knew the inserted ID even before actually inserting it. I'm quite sure that the INSERT ... RETURNING statement was not in the DBD::Oracle documentation 15 years ago, or else I would have used that instead.


        MS SQL Server uses INTEGER IDENTITY to create automatic IDs, you have to read them using SELECT @@IDENTITY. Triggers may mess with the returned value. (https://docs.microsoft.com/en-us/sql/t-sql/functions/identity-transact-sql) Overall, quite similar to MySQL.


        Update:

        erix suggested to change the PostgreSQL documentation links from 9.1 to current, i.e. https://www.postgresql.org/docs/current/static/datatype-numeric.html#DATATYPE-SERIAL and https://www.postgresql.org/docs/current/static/sql-insert.html. Well, yes, it could be useful, but my intention was to document old behaviour, not current, even if both are currently equal (at 9.6). So I linked to 9.1, and the links will stay that way. Maybe I should have linked to 8.2 instead, so here you are: https://www.postgresql.org/docs/8.2/static/datatype-numeric.html#DATATYPE-SERIAL and https://www.postgresql.org/docs/8.2/static/sql-insert.html

        Alexander

        --
        Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://1193789]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others pondering the Monastery: (6)
As of 2021-01-27 10:09 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?
    Notices?