Ik zit met een klein probleempje in het CMS van mijn website.
Deze biedt bij reviews, nieuws, etc. de mogelijkheid om tijdens het maken van een nieuw artikel een reeks foto's eraan toe te voegen. Echter, stoote ik tegen een probleempje aan, waar ik advies van anderen over wil hebben, en wil weten hoe zij dit opgelost hebben.

Vóórdat je het artikel opslaat zou je foto's kunnen toevoegen, deze staan met de bestandsnaam in de database opgeslagen zodat duidelijk is of ze bij de reviews/nieuws etc. horen en welk ID van hen.

Maar.... het ID is tijdens het schrijven nog niet bekend. Is het zinvol om de aanname te doen van het op dat moment recentste ID, en daar +1 bij te doen, of is dit riskant?

Hoe zouden jullie dit oplossen?
Zet het pas in de database als het artikel ook wordt opgeslagen, dan heb je gelijk het id.
Wordt lastig, want die foto's gaan niet direct met de POST van het formuliertje mee, omdat ze met PLupload worden geupload (meerdere tegelijkertijd kiezen).
Dan zou ik een eigen id/hash maken dat een eigen kolom in de database heeft en die meegeven aan je formulier en aan de foto's.
Lijkt me een goed idee.
Als ik het goed begrijp wil je afbeeldingen koppelen aan een niet-bestaand artikel.

Het probleem is dat het artikel niet bestaat, dan kun je dat daar ook het beste oplossen?

Wanneer je een nieuwe artikel maakt (begint te maken), creeer deze dan meteen in je database. Bij het "aanmaken" van je artikel ben je dus in feite al een (leeg, nieuw) artikel aan het editen.

Het probleem is nu niet direct dat je verlegen zit om auto_increment id's of dat de artikel-id's een aaneengesloten / onafgebroken reeks moeten vormen wel?

Het enige waar je dan in moet voorzien misschien is wat cleanup als je het "nieuwe" artikel niet opslaat.
Geen idee of dit echt kan maar misschien kan je met mysql de eerst volgende auto increment-id opvragen, en op basis daarvan de foto opslaan.
PHP Maarten op 09/07/2015 22:17:56

Geen idee of dit echt kan maar misschien kan je met mysql de eerst volgende auto increment-id opvragen, en op basis daarvan de foto opslaan.

Mja, maar zolang je deze niet claimt in een multi-user systeem is dit foutgevoelig:

A vraagt AI-id op: 12
A slaat vrolijk aan het typen
A voegt foto toe aan id 12
B vraag AI-id op: nog steeds 12
B typt wat sneller
B voegt een foto toe aan id 12
B slaat artikel op *claimt 12*
A slaat artikel op *claimt 13*

Game Over.

Tenzij je dit hele systeem wilt blokkeren zolang er één persoon aan het typen is?
Hmmmmmmm... no.
- Aar - op 09/07/2015 18:20:58

Maar.... het ID is tijdens het schrijven nog niet bekend. Is het zinvol om de aanname te doen van het op dat moment recentste ID, en daar +1 bij te doen, of is dit riskant?

Dit is spelen met vuur. Nooit doen dus.


Een eigen ID dus verzinnen, zoals @San aangeeft of eerst het artikel aanmaken (auto-increment) en dat ID overnemen.
a) in de tabel 'images' een extra kolom 'session_id' toevoegen.
b) foto's toevoegen in de tabel images en tevens session_id in de record opslaan
c) als het artikel wordt opgeslagen in de database een kleine routine inbouwen die er voor zorgt dat alle records die session_id xxx hebben worden geupdated:

UPDATE images SET newsarticle_id=? WHERE session_id=?


-- OF --

wanneer een gebruiker zijn eerste foto toevoegt in een nieuw artikel een routine inbouwen die
a) het artikel (al is het helemaal leeg) opslaat in de database en last_inserted_id teruggeeft.
b) foto wordt opgeslagen en id van nieuwsartikel is nu bekend.

Dat laatste geeft alleen weer problemen omdat als een gebruiker zich bedenkt en besluit het artikel niet op te slaan dan komt deze later toch dit artikel tegen. Je zou dus dan in newsarticle een extra kolom moeten toevoegen waarin je een boolean met de naam ACTIVE of TEMP aanmaakt...
Wat ik in deze situatie doe is eigenlijk vrij simpel.
Bij een nieuw item is het relatie ID altijd 0

Bij het opslaan zorg ik dat alle records die relatie id 0 zijn gekoppeld worden.
Zo heb je geen risico.

En als je dan nog zorgt dat bij het opnieuw laden van het formulier eventueel alle 'oude records' die nooit aan een hoofdrecord gekoppeld zijn verwijderd worden, krijg je ook geen loze records.

Reageren