Laatste ID en direct nieuwe inserts
Bij het registreren worden meerdere tabellen gevuld.
Ik gebruik nu:
Op grond daarvan doe ik aantal inserts in tabellen met de betreffende ID als referentie.
Nu dacht ik gelezen te hebben dat deze mogelijkheid in PHP 7 kwam te vervallen.
Maar is er een (veilige) mogelijkheid om dit anders te regelen?
Waar heb je gelezen dan dat dit komt te vervallen? In PDO blijft het gewoon bestaan, in mysqli ook.
Je hebt in principe gelijk.
Warning
This extension was deprecated in PHP 5.5.0, and it was removed in PHP 7.0.0. Instead, the MySQLi or PDO_MySQL extension should be used. See also MySQL: choosing an API guide and related FAQ for more information. Alternatives to this function include:
mysqli_insert_id()
PDO::lastInsertId()
Maar ik las ook bij het doorspitten van de info dat het niet altijd veilig is.
Als je bijv. bepaalde opdrachten meegeeft aan een insert dan klopt het niet meer.
Ik heb in de testfase ook wel eens de id nummering weer teruggezet naar het begin.
En dan ging die functie ook de mist in.
Vandaar ook tussen haakjes 'veilige' gezet.
Gewijzigd op 14/05/2016 00:28:25 door Hans De Ridder
Deprecated houd in dat ie vervalt in de volgende grote update. Dat is met insert_id zeker niet het geval.
Wat wel klopt is dat mysql al een behoorlijke tijd op de deprecated-lijst staat, maar als je MySQLi of PDO gebruikt ga dan vooral zo door.
(PHP 5, PHP 7)
mysqli::$insert_id -- mysqli_insert_id — Returns the auto generated id used in the last query
http://php.net/manual/en/mysqli.insert-id.php
Toevoeging op 13/05/2016 23:53:48:
Ben wel benieuwd waar jouw informatie vandaan komt, deze klopt totaal niet met php.net
Inderdaad. En de enige veilige methode om een autoincrement waarde terug te krijgen is via de insert_id functies van je database, of in PostgreSQL met de RETURNING syntax. Iedere andere methode (denk aan het selecteren van MAX(id) bijvoorbeeld) is inherent onveilig, denk aan race conditions etc. Wat wel belangrijk is, is dat je geen queries uitvoert tussen je INSERT en het opvragen van de zojuist opgehoogde autoincrement.
Ben van Velzen op 13/05/2016 23:57:41:
Wat wel belangrijk is, is dat je geen queries uitvoert tussen je INSERT en het opvragen van de zojuist opgehoogde autoincrement.
Dat kan wel. Als je de waarde van je insert_id maar in een variabele opslaat.
Wat dus het opvragen is he ;)
Info kwam o.a. van php.net.
Met name uit de reacties.
Maar waarschijnlijk vooral vanuit sql gedachte.
http://php.net/manual/en/function.mysql-insert-id.php
Quote:
(PHP 4, PHP 5)
mysql_insert_id — Get the ID generated in the last query
Warning
This extension was deprecated in PHP 5.5.0, and it was removed in PHP 7.0.0. Instead, the MySQLi or PDO_MySQL extension should be used. See also MySQL: choosing an API guide and related FAQ for more information. Alternatives to this function include:
mysqli_insert_id()
PDO::lastInsertId()
mysql_insert_id — Get the ID generated in the last query
Warning
This extension was deprecated in PHP 5.5.0, and it was removed in PHP 7.0.0. Instead, the MySQLi or PDO_MySQL extension should be used. See also MySQL: choosing an API guide and related FAQ for more information. Alternatives to this function include:
mysqli_insert_id()
PDO::lastInsertId()
mysql_insert_id (en last_insert_id) vervallen in php 5.5 en zijn niet aanwezig in php 7. Alternatieven zijn MySQLi en PDO.
Ik ben ook geen programmeur.
En haal nogal eens (te oude) voorbeelden bij anderen weg, die ik dan aanpas.
Zorg dat eerst alles functioneel is.
En als dit klaar is, dan pas ik alles aan zodat het ook bruikbaar is na PHP 5.6.
Is ook leerproces voor me met aardige toepassing als voorbeeld.
Quote:
En als dit klaar is, dan pas ik alles aan zodat het ook bruikbaar is na PHP 5.6.
Dat klinkt als een huis bouwen en er vervolgens een schuur van maken.
Doe je de ontwikkeling lokaal of online? Het is handig dit lokaal (dus op je eigen pc) te doen en daar kun je dan kiezen voor bijv PHP 7*. Dan weet je zeker dat je geen functies gebruikt die niet meer bestaan. Daarna kun je alles uploaden en dan ben je voor de volgende update ook klaar. Voordeel van lokaal is dat je een test omgeving hebt waar je bezoekers geen hinder van hebben en je ook gelijk een kopie van je website hebt.
Edit: * Let er dan natuurlijk wel op dat je ook geen functies gebruikt die zijn toegevoegd in PHP 7. Je kan ook de laatste versie van 5 installeren en alle foutmeldingen aanzetten dan krijg je ook een waarschuwing wanneer een functie die je gebruikt komt te vervallen.
Gewijzigd op 14/05/2016 11:14:17 door Michael -
Zit nu op PHP 5.6.
Ik gebruik al jaren gewoon mijn kladblokje. (Of een wat luxere versie)
Dan begrijp ik teniminste wat er gebeurt.
Als ik wat met PHP moet testen gaat dat gewoon via FTP naar de site toe in map.
Ik weet dat er volop software is, maar is gewoon hobby voor me (ben 2 x 32).
Maar gaat goed zo.
Ik krijg alles nog voor elkaar wat ik wens.
En anders is er dit mooie forum nog.
En leer toch het beste door te testen waar iets fout gaat.
En soms ontdek ik dat bij een volgende versie wat verkeerd gaat.
Als alles in principe functioneert dan loop ik het nog eens door.
Dan moet alles eruit wat specifiek mysql is.
En zo is er wel meer.
Bedankt overigens voor je goede adviezen.
Gewijzigd op 14/05/2016 12:59:38 door Hans De Ridder
i_-functies door elkaar te gebruiken. Je zult dus in 1x over moeten van de mysql-extensie naar de mysqli-extensie. Deze overstap was een stuk vloeiender geweest als je een wrapper-class had voor mysql-functies. Het enige wat je dat hoefde te doen was het veranderen van de implementatie van die wrapper class, in plaats van alle instanties van mysql_-aanroepen te search-and-replace-en. Als je nu slim ben schrijf je nu wel een wrapper class zodat je de volgende keer niet weer voor hetzelfde probleem staat.
Dit kun je niet altijd afdwingen (denk aan verschillende users/threads die dezelfde informatie bekijken). Daartoe is het zaak dat je een batch wijzigingen altijd in een transactie zet met bijbehorende FOR UPDATE toevoegingen om relevante tabellen/kolommen tijdelijk te locken. Dat is de enige manier om op elk moment consistentie in je data af te dwingen.
Overigens is het opvragen van insert id's thread specifiek geloof ik. Dus als Jantje en Pietje allebei iets toevoegen en er direct opgevraagd wordt welk id het toegevoegde item bevat krijgen Jantje en Pietje allebei braaf hun eigen insert id terug. Neemt niet weg dat er op andere plekken wel dingen door elkaar kunnen lopen. Daarvoor zijn transacties.
Als je dit na wilt spelen in een script houd er dan rekening mee dat als je "verschillende" connecties (connectie-objecten) gebruikt dat deze mogelijk dezelfde fysieke connectie gebruiken indien de argumenten voor het maken van een connectie hetzelfde zijn.
Het ging dus niet specifiek over "insert id" functionaliteit, maar het feit dat je je bedient van een mysql_-functie. Het lijkt mij ook niet verstandig om mysql_-functies en mysqlBen van Velzen op 13/05/2016 23:57:41:
Wat wel belangrijk is, is dat je geen queries uitvoert tussen je INSERT en het opvragen van de zojuist opgehoogde autoincrement.
Dit kun je niet altijd afdwingen (denk aan verschillende users/threads die dezelfde informatie bekijken). Daartoe is het zaak dat je een batch wijzigingen altijd in een transactie zet met bijbehorende FOR UPDATE toevoegingen om relevante tabellen/kolommen tijdelijk te locken. Dat is de enige manier om op elk moment consistentie in je data af te dwingen.
Overigens is het opvragen van insert id's thread specifiek geloof ik. Dus als Jantje en Pietje allebei iets toevoegen en er direct opgevraagd wordt welk id het toegevoegde item bevat krijgen Jantje en Pietje allebei braaf hun eigen insert id terug. Neemt niet weg dat er op andere plekken wel dingen door elkaar kunnen lopen. Daarvoor zijn transacties.
Als je dit na wilt spelen in een script houd er dan rekening mee dat als je "verschillende" connecties (connectie-objecten) gebruikt dat deze mogelijk dezelfde fysieke connectie gebruiken indien de argumenten voor het maken van een connectie hetzelfde zijn.
Gewijzigd op 14/05/2016 14:55:31 door Thomas van den Heuvel