Foto's opslaan vóórdat je een ID hebt
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.
Gewijzigd op 09/07/2015 18:56:25 door - Ariën -
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.
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.
Gewijzigd op 09/07/2015 22:23:53 door Thomas van den Heuvel
- 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.
Gewijzigd op 09/07/2015 23:38:43 door Paco de Wulp
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:
-- 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...
Gewijzigd op 10/07/2015 00:03:42 door Frank Nietbelangrijk
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.
Robert Wazzaa op 10/07/2015 00:06:12:
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.
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.
En als er meerder gebruikers tegelijk bezig zijn dan? :o
Frank Nietbelangrijk op 10/07/2015 00:08:21:
En als er meerder gebruikers tegelijk bezig zijn dan? :o
Robert Wazzaa op 10/07/2015 00:06:12:
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.
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.
En als er meerder gebruikers tegelijk bezig zijn dan? :o
dan staat het record aan de gebruiker gekoppend met het record id 0
Dus zou het geen probleem moeten geven.
Henk voegt een foto toe: en user_id=0
Fred voegt een foto toe: en user_id=0
Henk bewaart zijn artikel en deze wordt in de database opgeslagen als artikel_id=456
en dan???
Ik zal SanThe's manier aanhouden. Een SessieID moet het uniek maken.
In de rewrite van mijn CMS ga ik uiteraard alles in gewoon direct in een en dezelfde POST-request van het invoer-formulier gebruiken, dat bespaart een hoop geklooi.
Frank Nietbelangrijk op 10/07/2015 00:23:27:
Dus:
Henk voegt een foto toe: en user_id=0
Fred voegt een foto toe: en user_id=0
Henk bewaart zijn artikel en deze wordt in de database opgeslagen als artikel_id=456
en dan???
Henk voegt een foto toe: en user_id=0
Fred voegt een foto toe: en user_id=0
Henk bewaart zijn artikel en deze wordt in de database opgeslagen als artikel_id=456
en dan???
Robert Wazzaa op 10/07/2015 00:06:12:
Wat ik in deze situatie doe is eigenlijk vrij simpel.
Bij een nieuw item is het relatie ID altijd 0
Bij een nieuw item is het relatie ID altijd 0
Ik hoop dat je NULL bedoelt als je het over database-termen hebt. Je slaat toch niet letterlijk "0" op?
Robert Wazzaa op 10/07/2015 00:06:12:
Bij het opslaan zorg ik dat alle records die relatie id 0 zijn gekoppeld worden.
Zo heb je geen risico.
Zo heb je geen risico.
Nog nooit te maken gehad met sessie-timeouts door wat voor reden dan ook?
@Aar, ik zou gewoon het oorspronkelijke probleem wegnemen in plaats van voor een (IMO) moeilijkere oplossing gaan.
Gewijzigd op 10/07/2015 00:31:00 door Thomas van den Heuvel
Nee ik bedoel wel zeker een 0. is ook gewoon een waarde in de database.
Dat gaat toch niet werken met foreign keys / foreign key constraints, of gebruik je deze niet?
ik gebruik die niet nee.
Thomas van den Heuvel op 10/07/2015 00:28:54:
@Aar, ik zou gewoon het oorspronkelijke probleem wegnemen in plaats van voor een (IMO) moeilijkere oplossing gaan.
Maar als je nu een moderne AJAX foto upload wilt zoals deze en dit op dezelfde pagina waar je een nieuw nieuws artikel aanmaakt?