Ik heb het gevoel dat ik de verkeerde titel toe ken aan mijn ge-uploaden afbeeldingen. Ik vraag me ook af of ik de titel wel moet md5'en ?
Dit is belangrijk i.v.m. een eventuele back-up.
Lokaal ziet de structuur er zo logischerwijs uit:
Desktop>IMG>categorie>Afbeelding1.JPG, afbeelding(2).JPEG. etc.
In mijn FTP map afbeeldingen ziet de titel er zo uit (voorbeeld):
23efwefwefwef32wefwef23efwefwef Afbeelding1.JPG
Bij een eventuele crash wil ik gewoon de afbeeldingen die lokaal staat, direct kunnen uploaden naar de desbetreffende map, zonder dat ik eerst de titel door md5 heen haal (want de 32 karakters is de versleutelde afbeelding naam).
Wat is een goede structuur om de afbeeldingen (3/6 per post) een passende titel te geven?
Misschien kun je wat meer vertellen over het systeem, wat precies met de afbeeldingen gebeurt enzovoorts. Zal vast een reden van de ontwikkelaar geweest zijn om toe te passen, denk ik.
Maar wat als verschillende afbeeldingen uit verschillende bronnen toevallig eenzelfde naam hebben? Krijgen deze dan dezelfde hash? Wordt een van de twee dan overschreven? Treedt er dan een foutmelding op? Hoe werkt dit precies?
Beter om ze gewoon allemaal (apart) op te slaan. De hash zou compleet "random" moeten zijn lijkt mij. En dan is de vraag, heb je een soort van WYSIWYG-editor om afbeeldingen op te nemen in je artikelen?
Het klinkt alsof je direct een passende oplossing wilt voor een -voor ons verder- onbekend systeem waarvan je meerdere schakels in één keer beschrijft (het uploaden vn afbeeldingen, het opnemen van deze afbeeldingen in een artikel, het weergeven van dit artikel). Het is daarom nogal moeilijk zoniet onmogelijk om dan direct te zeggen "oh, dan moet je dit of dat doen".
De beste "passende titel" lijkt mij nog altijd een omschrijving van het afgebeelde opnemen in de bestandsnaam. vakantie-zeeland-2015-zonsondergang.jpg vertelt je al een heleboel zonder de afbeelding ook maar gezien te hebben. Ook kan de alt- en/of het longdesc-attribuut van de img-tag uitkomst bieden. Afbeeldingen kunnen zelf ook metadata met zich meedragen.
Ik zou in ieder geval een andere manier verzinnen om te bepalen of verschillende afbeeldingen duplicaten van elkaar zijn (als dat het probleem is?). Maar eerst zul je duidelijkheid moeten krijgen over hoe het naamgevingsproces originele bestandsnaam > gehashte bestandsnaam verloopt.
Als het puur gaat om het maken van backups lijkt het mij dat de online content "leading" dient te zijn. Daar zul je dus (geregeld) backups van moeten draaien. Als het ontwerp goed is staat alle geuploade content op één plaats, zodat je daar makkelijk een (tarred) zip van kunt bakken. Daarnaast zou er een database-dump faciliteit moeten zijn zodat je makkelijk een backup kunt maken van je database. En tot slot zou je code geversioned moeten zijn, of je zult hier in ieder geval op een of andere backup van moeten hebben.
Het lijkt mij om meerdere redenen handig om je online versie te bestempelen als "leading" en te zorgen dat je je site (content + database + code) regelmatig backupped, en dat dit makkelijk is. Te meer omdat nog niet precies duidelijk lijkt hoe de uploads precies werken? Wat wil je na een crash doen? Alle bestanden weer in een bepaalde volgorde uploaden en allerlei truuks uithalen, dan lijkt mij het terugzetten van een database/content backup een stuk makkelijker?
Maar goed, dit vraagstuk bestrijkt meerdere aspecten, dus ik weet niet precies wat je wilt, noch wat voor dingen je gebruikt of wat voor middelen je al tot je beschikking hebt. Ik zou beginnen met het maken van een verkenning van de werking en het opstellen van een procedure voor het maken van backups en het terugzetten hiervan. Een soort van reverse engineering van je eigen product dus . Waar normaal al documentatie voor zou moeten zijn...
Fangorn, bedankt voor je reactie. In tegenstelling tot jouw bericht ben ik inderdaad wat kort en onduidelijk begonnen.
Ik wil ook beter het overzicht bewaren dan 1000+ afbeeldingen in 1 map (tarred zip).
1. De titels van de afbeeldingen dienen als illustratie, in het echt zien ze er zo uit:
laptophoes_waterdicht.jpg; laptophoes_wachterdicht(1).jpg. etc. deze herken ik dus wel.
2. Website leading ? nou in principe moet het gelijk zijn aan wat ik lokaal heb staan, daar wil ik zo min mogelijk onderscheid in hebben.
3. Duplicaten komen niet (nauwelijks) voor, ik voeg alles handmatig toe, dus dit zou eigenlijk niet voor komen.
Het is wel zo dat ik de afbeelding voor meerdere posts gebruik.
4. Ik wil in ieder geval van de hash af, dit wordt bij het terugzetten van de afbeeldingen een probleem.
5. Als ik een kopie van een record maak in de tabel "ads", dan wordt de content gedupliceerd, maar de afbeeldingen zijn bij de weergaven van de advertentie niet zichtbaar.
5. kan BLOB geen uitkomst bieden ?
[edit] procedure / werking van het systeem:
Ik haal van mijn partner (importeur) met toestemming de content van de pagina > Ik upload de afbeeldingen, voeg de teksten in > Sla de add op in de DB.
Bij het opslaan van de afbeeldingen zien de titels er als volgt uit:
productafbeelding.jpg, productafbeelding(1).jpg, vervolgens kan ik bij het uploaden zien wat het meest recente opgeslagen afbeelding is, dit werkt redelijk snel. Ik code liever een goed systeem dan dat ik bij het opslaan de titels wijzig naar de code.
Ja ik werk met een partner, en ja er is een feed, maar ik heb zo mijn reden om het handmatig toe te voegen.
Zoals ik het zie vindt er als je een afbeelding uploadt een soort van aanpassing plaats. Immers, zoals je zelf aangeeft, als je iets upload van de vorm afbeelding.jpg dan staat er vervolgens in een of andere content-map 23efwefwefwef32wefwef23efwefwef Afbeelding1.JPG of wat dan ook.
Dit doet het systeem waarschijnlijk, en zal dus ook een of andere reden hebben (wij kunnen er -zonder code, annotatie in code of documentatie- slechts naar gissen). Feit is wel dat het systeem deze aanpassing heeft verricht die mogelijk betekenis heeft binnen dit systeem. De twee afbeeldingen zijn dus niet meer equivalent.
Mogelijk heeft het systeem informatie bij deze afbeelding opgeslagen (dataverrijking?) waarbij ook een koppeling bestaat tussen de informatie in de database en de (nieuwe) bestandsnaam van het geuploade bestand. Hier bestaat dan dus een relatie/afhankelijkheid tussen. Het lijkt mij dan verstandig (als er sprake van een afhankelijkheid is) om deze twee zaken (geuploade afbeeldingen, database) gezamenlijk te behandelen, want dit vormt dan samen één geheel.
Je zegt:
Citaat:
Bij een eventuele crash wil ik gewoon de afbeeldingen die lokaal staat, direct kunnen uploaden naar de desbetreffende map, zonder dat ik eerst de titel door md5 heen haal (want de 32 karakters is de versleutelde afbeelding naam).
De makkelijkste manier is dan toch een exacte kopie maken van die map, en die dan weer terugzetten? (je zult dan ook een recente backup van zijn tegenhanger -de database- moeten hebben als er verbanden tussen deze twee bestaan)
Ik zie niet helemaal in waarom je via een andere weg hetzelfde resultaat wilt kunnen reproduceren. Dit kun je ook niet goed doen zonder dat je precies weet hoe het systeem werkt. Daarnaast zit je onlosmakelijk aan dit systeem verbonden, want deze voert een of meer (on)bekende aanpassingen uit. Het systeem bepaalt uiteindelijk hoe dit werkt. Ik zou dan gewoon gebruik maken van de "output" die het systeem zelf produceert. Het maakt dan niet meer uit hoe deze "black box" werkt. Als je van alle content van het systeem een backup hebt dan kun je de "toestand" van het systeem altijd herstellen, ongeacht hoe deze werkt.
Bedankt voor de reactie. Zodra ik de SQL back-up invoer, en de map afbeeldingen weer upload, dan zijn de hashes niet gelijk neem ik aan ?
Dat weet ik niet. Ook weet ik niet wat de interactie is tussen db en bestanden. Al wat ik weet is dat wanneer je de complete "toestand" van een systeem vangt, je deze ook weer 1:1 kunt terugzetten. Vergelijk het met het maken van een image van je systeemschijf. Het enige wat je dan doet als je een backup wil terugzetten is de image kopiëren.
Wat jij nu wilt doen (of in ieder geval voorstelde, met het opnieuw uploaden van alle bestanden) is toch ongeveer equivalent met een format en een handmatige installatie van het OS + alle programma's die je eerder gebruikte . Waarom zou je dat doen als je simpelweg de "image" kunt terugzetten?
Gesponsorde links
Je moet ingelogd zijn om een reactie te kunnen posten.