[php] mysql_insert_id() voor een 2de keer aanspreken

[Zakkenwasser]

Ik kom terug op een vorige post, maar zal dit keer wat accurater wezen in wat ik precies bedoel en waar het mis gaat.

Mijn geschreven programma moet na het uploaden van een afbeelding, deze kleiner maken en tegelijke tijd het orgineel ook opslaan in 2 aparte mappen op de server.

Het orgineel wordt opgeslagen in map images
De ge-resizde copy van dezelfde image wordt opgeslagen in map thumbs

Terwijl mijn programma dit allemaal verwerkt, spreek ik MySQL aan.

[code=php]$extensie = $extensie[0];
$sql = "INSERT INTO Thumbnails (post_id, Bestandstype) VALUES (".$_POST["artikelid"].", '$extensie')";
$doelbestandsnaam = mysql_insert_id().$extensie; // naam bestaat uit sleutel en extensie
if (!move_uploaded_file($_FILES['afbeelding']['tmp_name'], $pad.$doelbestandsnaam)) {
echo "Het bestand kan niet verplaatst worden!";
}
[/code=php]

Als dit gedaan is wordt het orgineel doorgespeeld naar:
[code=php]
$extensie = $extensie[0];
$sql = "INSERT INTO Afbeelding (post_id, Bestandstype) VALUES (".$_POST["artikelid"].", '$extensie')";

$name = mysql_insert_id();

$success = imagejpeg($thumb, THUMBS_DIR.$name.'.jpg', 50);
$thumb_name = $name.'.jpg created';
}
if ($success) {
$result = "$thumb_name created";
[/code=php]

Eerste probleem waar ik tegenaan ben gelopen:
Map thumbs bevat 0.jpg
Map images bavat 1.jpg

Wat ik onder andere heb geprobeerd:
1 $name = mysql_insert_id() + 1;
2 $name = mysql_insert_id() ++ 1;

Resultaat
1 De plaatjes in beide mappen zijn nu gelijk, alleen is dit voor eenmalig, waardoor dit weer niet juist is.
2 Fatal error: Can't use function return value in write context in /storage/mijndomein/users/108498/public/sites/www.overdatum.nl/testt/includes/create_both.inc.php on line 23

[ Voor 6% gewijzigd door Zakkenwasser op 05-11-2008 22:45 ]

[CodeCaster]

Je bent zo te zien al bekend met het gebruik van variabelen. Wat zou de volgende code doen?

PHP:

$image_id = mysql_insert_id();

// {knip}
$targetfilename = $image_id.$extensie;

// {knip}
$thumb_name = $image_id.'.jpg';

?

[crisp]

Ik gok op een discrepantie in het auto_increment id tussen je tabellen 'Thumbnails' en 'Afbeelding'

Oplossing: geef expliciet de id die je verkrijgt vanuit je insert in 'Thumbnails' op als id voor 'Afbeelding'

edit: of zoals Cheatah hieronder zegt: voeg ze samen...

[ Voor 12% gewijzigd door crisp op 05-11-2008 22:46 ]

[Verwijderd]

Je zit eerder met een gedachtenkronkel. Als je een tabel hebt voor afbeeldingen, waarom heb je dan in vredesnaam een andere tabel voor thumbnails? Waarom niet gewoon een aparte directory voor thumbnails met verder exact dezelfde naam? Waarom niet in dezelfde directory een thumbnail met een afgeleide naam, zoals "thumb-$bestandsnaam.$extensie"?

Voortaan niet meer met code je ontwerpfouten proberen op te lossen.

[Kettrick]

Waarom hou je uberhaubt twee tables bij als je toch altijd dezelfde bestanden hebt in /thumbs en /images ?.

Je ID's in je tables lopen nu waarschijnlijk niet gelijk, waardoor je hele rare situaties krijgt

[ Voor 0% gewijzigd door Kettrick op 05-11-2008 22:45 . Reden: spuit 11... ]

[Zakkenwasser]

RoeLz schreef op woensdag 05 november 2008 @ 22:45:
Waarom hou je uberhaubt twee tables bij als je toch altijd dezelfde bestanden hebt in /thumbs en /images ?.

Je ID's in je tables lopen nu waarschijnlijk niet gelijk, waardoor je hele rare situaties krijgt

De reden is omdat ik deze het geresizesde plaatje op de frontpage wil laten komen, en deze doorlinken naar het orgineel.

[TeeDee]

Dat kan toch ook prima in één tabel?

[Kettrick]

inderdaad, als je uit een of andere relatie ( product, gebruiker, whatever) weet dat je plaatje 10 wil doe je /images/10.jpg of /thumbs/10.jpg, vooral niet te moeilijk doen

[Zakkenwasser]

Ik zie inderdaad dat er wat ontwerp fouten zijn gemaakt.

Ik zal het programma morgen of overmorgen als ik tijd heb opnieuw herschrijven naar de juiste manier.

Het zou inderdaad wat prettiger wezen als dit ala tutorial ergens te vinden is, maar daarintegen leer ik veel meer vna mijn fouten en van het zelf proberen.

Het is niet de bedoeling om jullie iedere keer te storen met de problemen waar ik tegenaan loop.
door tekortkoming van mij
Suggestie's zijn altijd welkom.

[ Voor 6% gewijzigd door Zakkenwasser op 05-11-2008 23:42 ]

[Gomez12]

Ok, hoeveel hits denk je te gaan krijgen?
Want door het op dit moment te gaan thumbnailen ben je wel efficienter bezig, maar je haalt je een stuk complexiteit op je hals ( wat doe je als je je resolutie van je thumbs wilt veranderen? Want doe je als je als je met ftp een beter origineel / ander origineel neerzet etc.etc. )

Persoonlijk ga ik bij een low tot medium traffic site liever naar on the fly thumbnailen met een grote cache erachter ( bijv via phpthumb ), zodat er bij elke missende / nog niet aangemaakte thumb automatisch een nieuwe aangemaakt wordt, bij elk nieuw origineel komt er ook een nieuwe, alle oude nooit bekeken worden met redelijke caching regels standaard verwijdert en opnieuw aangemaakt als het nodig is.

Je wilt je thumbs in een andere resolutie / andere kwaliteit hebben, verander de aanroep regel en je cache wordt vanzelf opgeschoond en je nieuwe thumbs worden automatisch aangemaakt.

Is alleen redelijk nadelig als je 1000 nieuwe images op een pagina wilt tonen ( want dan zit je gewoon even te wachten ) of als je zo ver aan het optimaliseren bent dat die ene check of het al in je cache staat je al teveel performance gaat kosten ( maar dan kan je ook wel met de rest van de bezwaren overweg neem ik aan ).

Heb je alleen op een echte high-traffic site nog een risico dat als 1000 mensen op hetzelfde tijdstip hetzelfde plaatje willen zien dat doordat het 1e on the fly nog niet klaar is dat er een 2e proces gestart wordt wat de 1e vertraagd waardoor je op een gegeven moment op een deadlock uit kan komen, maar dit is redelijk te ondervangen door gewoon na het uploaden al gelijk via dezelfde functie een preview te tonen aan de uploader ( dan is er al een cache-item aangemaakt )

[Zakkenwasser]

Gomez12 schreef op donderdag 06 november 2008 @ 00:30:
Ok, hoeveel hits denk je te gaan krijgen?
Want door het op dit moment te gaan thumbnailen ben je wel efficienter bezig, maar je haalt je een stuk complexiteit op je hals ( wat doe je als je je resolutie van je thumbs wilt veranderen? Want doe je als je als je met ftp een beter origineel / ander origineel neerzet etc.etc. )

Ik ben een perfectionist.

Ik begon een jaar geleden met tabellen, daar ben ik toen uren lang mee bezig geweest om iedere rij / kollom pixel perfect op elkaar aftestemmen.

Dit was niet de manier, en ben met CSS gaan werken, dit ben ik tot op de dag van vandaag nog steeds meer aan het perfectioneren, maar dat ter zijde.

Ik ben nu met het CMS bezig. en ik wil dat mijn site op het gebied van snelheid en laden gewoon super is, alles volgends de regels en richtlijnen om het maar te zeggen.

Als ik mijn plaatjes nu simpel zou uploaden, dan vliegt mijn design en mijn hele idee van snelheid winst op iedere kbyte zo het raam uit
.
Liever dan maar complexer,ik ben heb er veel passie voor + ik leer er meer van, en ik doe het volgends de richtlijnen..

Ik verwacht veel bezoekers, en wil een ander concept neerzetten in nederland.
Geen reclame bullshit, gewoon iets met passie delen, en naamsbekendheid kweken, zodat ik met mijn open mind kan laten zien, dat niet alles om geld draait.

Op die manier wil ik ook meer kwaliteit op internet brengen.

en zodra ik passie voor iets heb, dan wil ik het ook tot op de bodem uitzoeken.

+ dat ik niet overal photoshop of andere opensource progs die het resizen handmatig mogenlijk maken kan installeren.
Ik wil het desnoods zo maken dat ik zelfs via mobiele direct kan uploaden, als ik iets spot.

[ Voor 9% gewijzigd door Zakkenwasser op 06-11-2008 07:47 ]

[MueR]

Perfectionisme is leuk, maar uit eerdere ervaring kan ik je vertellen dat doorgaans, bij hobby sites, het niet nuttig is. Je bent vaak heel erg lang bezig met een onderdeel, met vallen en nog harder vallen leer je veel. Tot je toevallig ergens een idee voorbij ziet komen waarop het nog efficienter kan. Uiteindelijk ben je maar vrij weinig aan het doen.

Mijn advies, als amateur en professioneel developer: hou het simpel. Die thumbnails kan je later ook nog maken.

[Voutloos]

Aan de andere kant hoeven thumbnails ook echt geen rocket science te zijn...

[MueR]

Klopt Voutloos. Is het ook niet. Maar uit zijn verhaal maak ik op dat ie al een jaar bezig is. Voor een hobby site is dat wat veel

[Voutloos]

Dat komt omdat TS stelselmatig wanneer hij 3 vars in een db wil opslaan met een datamodel met 42 tabellen en 1337 aan komt zetten. Zie ook in dit topic de KISS hint van Cheatah.

[Cartman!]

Je kunt ook tijdens het opvragen van de thumb controleren of ie al bestaat, zo niet dan maak je hem direct aan, en zo wel...dan doe je niks en laat je em gewoon zien. Wil je een andere resolutie thumbs? Dan gooi je de map met thumbs leeg en pas je de hoogte/breedte van je resize functie aan. Is een hele simpele oplossing die vaak wel voldoende is.

[mcdronkz]

Cartman! schreef op donderdag 06 november 2008 @ 11:24:
Je kunt ook tijdens het opvragen van de thumb controleren of ie al bestaat, zo niet dan maak je hem direct aan, en zo wel...dan doe je niks en laat je em gewoon zien. Wil je een andere resolutie thumbs? Dan gooi je de map met thumbs leeg en pas je de hoogte/breedte van je resize functie aan. Is een hele simpele oplossing die vaak wel voldoende is.

Da's waar, maar anderzijds vereist het on-the-fly maken van thumbs nog minder handelingen. Immers, je zult nu de thumbnail altijd in een extra map moeten laten plaatsen, het is veel makkelijker om een simpele URL rewrite te maken in een .htaccess van "/thumbs/5235325.jpg" naar "thumbs.php?file=5235325".

Lijkt me zeker in dit geval de handigste oplossing, en of je nu perfectionist bent of niet, dit kun je heel fraai maken als je wilt.

Op mijn eigen site sla ik de thumbnails trouwens wel lokaal op, maar dat komt omdat m'n foto's op flickr staan en ik expliciet zwart/wit thumbnails wil (ja, echt..). Mocht flickr.com down gaan, dan zijn er in elk geval thumbnails op m'n site te zien. Maar dat is in dit geval niet echt van belang.

[ Voor 14% gewijzigd door mcdronkz op 06-11-2008 11:41 ]

[Voutloos]

Goed plan, (continu, zonder cache) on-the-fly thumbs scalen is wel 1 vd betere manieren om je CPU dicht te trekken. Er moeten echt zat tutorials zijn, want menig faalhaas heeft reeds het on-the-fly pad bewandeld en inmiddels beter geleerd.

Als het cachen van thumbs een probleem is, is het gebruiken van thumbs blijkbaar toch te hoog gegrepen en kan je het toch maar beter even laten.

[ Voor 28% gewijzigd door Voutloos op 06-11-2008 12:03 ]

[Cartman!]

Inderdaad, als je ineens een paar honderd man op je site hebt die allemaal on-the-fly thumbs gaan laten maken, dat gaat je webserver niet tof vinden. Begin dan ook niet aan on-the-fly thumbnailen maar cache ze netjes na t maken. Het is een kleine handeling meer maar o zo handig

Immers, je zult nu de thumbnail altijd in een extra map moeten laten plaatsen

Dus? Wat is hier een nadeel van dan...?

[curry684]

Cartman! schreef op donderdag 06 november 2008 @ 11:51:
Begin dan ook niet aan on-the-fly thumbnailen maar cache ze netjes na t maken.

Uh schrijf dan die 3 regels code op de goede plek, die netjes de filemtime van origineel en thumb vergelijkt, op basis daarvan al of niet on-the-fly een thumbnail maakt, en die braaf opslaat op de servert.

On-the-fly is the way to go als je maar de brains hebt om ze te cachen en goede stale detection direct inbouwt, ik kan je met praktijkkennis vertellen dat je daarmee moeiteloos tienduizenden hits per uur mee kunt verwerken op een mediumpower server.

[mcdronkz]

Cartman! schreef op donderdag 06 november 2008 @ 11:51:
Inderdaad, als je ineens een paar honderd man op je site hebt die allemaal on-the-fly thumbs gaan laten maken, dat gaat je webserver niet tof vinden. Begin dan ook niet aan on-the-fly thumbnailen maar cache ze netjes na t maken. Het is een kleine handeling meer maar o zo handig


[...]

Dus? Wat is hier een nadeel van dan...?

Dat gaf je in principe zelf al aan, als je iets aan de thumbnails zou willen veranderen moet je ze eerst weer verwijderen en daarna opnieuw laten genereren.

Maar ik ben niet helemaal achterlijk natuurlijk, als je inderdaad een paar honderd man op je site krijgt moet je helemaal niet denken aan het on-the-fly genereren. Maar als je een site hebt waarop alleen je familie komt en je verder nog 3 hits per jaar krijgt ontgaat me het voordeel van cachen een beetje.

[Cartman!]

curry, inderdaad maar ik hoef niet alles voor te kauwen hier, of wel?

mcdronkz : de TS geeft aan dat ie alles slim wil maken dus dan gaan we er ook vanuit dat ie dat ook daadwerkelijk wil doen. Alsnog aanraden ze elke keer on-the-fly te cachen is dan niet handig.

[Zakkenwasser]

het on-the-fly maken van thumbs is natuurlijk alleen voor admin, en niet voor debezoeker
Laat dat duidenlijk wezen

[Kettrick]

MrJey schreef op donderdag 06 november 2008 @ 13:38:
het on-the-fly maken van thumbs is natuurlijk alleen voor admin, en niet voor debezoeker

Ik genereer thumbnails on the fly voor bezoekers, als ze niet in de cache staan. Zo gek is dat dus niet . De eerste bezoeker moet dan 0.01 seconde wachten, heb er nog geen klachten over gehad

Het voordeel daarvan is echter wel dat het hele concept thumbs alleen maar op de voorkant zit, en volledig los staat van overige cms taken.Klant voegt iets toe, systeem regelt de aanmaak en caching van de thumbs.

[koekiemonster]

Als een gebruiker in het CMS wat meer wachttijd heeft, dan is dat minder erg dan de bezoeker die moet wachten op haar plaatjes. Die insteek zou ik in ieder geval nemen....

[Zakkenwasser]

koekiemonster schreef op donderdag 06 november 2008 @ 17:28:
Als een gebruiker in het CMS wat meer wachttijd heeft, dan is dat minder erg dan de bezoeker die moet wachten op haar plaatjes. Die insteek zou ik in ieder geval nemen....

Het is ook inderdaad de bedoeling tijd winst te genereren voor de eindgebruiker, de bezoeker om het zo maar aan te duiden.

het boeit mij niet dat het uploaden in CMS nou 1 of 2 seconden langer duurd, als de compresie maar wordt toegepast..

maarja zit nu in een pauze op mijn werk en heb koop avond, dus weinig te doen voor vanavond, behalve wat op php.net rondstruinen en wat kennis opdoen

[RobIII]

koekiemonster schreef op donderdag 06 november 2008 @ 17:28:
als de compresie maar wordt toegepast..

compressie != thumbnailing. Sure, een thumbnail zal compressed zijn als jpg/gif whatever, maar dat is een 'gewone' afbeelding ook.

[Kettrick]

koekiemonster schreef op donderdag 06 november 2008 @ 17:28:
Als een gebruiker in het CMS wat meer wachttijd heeft, dan is dat minder erg dan de bezoeker die moet wachten op haar plaatjes. Die insteek zou ik in ieder geval nemen....

Het eenmalig genereren van thumbnails zorgt niet voor een merkbare vertraging, de volgende bezoeker krijgt de cached plaatjes te zien en heeft dus nergens last van.

Overigens gebruik ik dezelfde thumbs in mijn cms al, dus in vrijwel alle gevallen zijn ze al gegenereerd voordat de eerste bezoeker komt

[Gomez12]

MrJey schreef op donderdag 06 november 2008 @ 17:56:
[...]

Het is ook inderdaad de bedoeling tijd winst te genereren voor de eindgebruiker, de bezoeker om het zo maar aan te duiden.

het boeit mij niet dat het uploaden in CMS nou 1 of 2 seconden langer duurd, als de compresie maar wordt toegepast..

Dan toon je toch gewoon een preview (=thumb) in het CMS na het uploaden?

Dan genereer je ze nog steeds on the fly ( mits niet gecached ), alleen doordat je in het cms al een preview toont is hij gelijk gecached.
Gaat er iets fout waardoor je enkele thumbs kwijtraakt / nieuwe plaatjes aangeleverd krijgt buiten het cms om, dan staat je werkwijze nog steeds als een huis, de 1e gebruiker genereert dan de image en de andere gebruikers worden bediend vanuit de cache.
Mits je stale detection goed is heb je nooit meer omkijken naar je thumbnails. Is hij er niet wordt hij aangemaakt, is hij er wel dan wordt hij getoond.

Dingen als thumbnailen etc wil je gewoon geen omkijken naar hebben. Dat moet gewoon werken. Ik wil in ieder geval bij een server-move bijv geen rekening hoeven te houden met thumbnails etc