-
Notifications
You must be signed in to change notification settings - Fork 7
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
S3 naar B2 #73
S3 naar B2 #73
Conversation
Is er een reden dat we niet |
Omdat je een RAW file contents terug krijgt. Deze moet je dan encoden met base64. Dit duurde tijdens het uploaden vrij lang en om die reden ook verwijderd bij het ophalen van bestanden. |
Helder! Heb even gezocht, en volgensmij is de URL gewoon bucket specifiek, zou dus opzich geen probleem moeten zijn. Dan lijkt het me wel zo netjes om de bucket URL even in de .env file te zetten ipv direct in de code. Hoe denk jij hierover? |
Yes, dat is inderdaad beter, zal het fixen |
Signed-off-by: Indie <indiepeeters@hotmail.com>
Signed-off-by: Indie <indiepeeters@hotmail.com>
@wouterbles Kan ik deze mergen? Fixed #55 en #61 |
Is het nog een idee om een migratie aan te maken die de huidige DB entries in de foto tabel verwijderd? Weet niet of dit best practice is? Maar anders moeten we handmatig gaan kloten op de live server database. Ook is de seeder nog niet geüpdate denk ik? Oh en over die bucket url doelde ik eigenlijk op de volledige URL. Het f002 gedeelte wat er voor staat is wat ik uit de docs begreep namelijk ook bucket specifiek. |
Table truncates zou ik niet in een migration zetten, deze is echt bedoeld voor structurele wijzigingen voor zo ver ik weet. |
Seeder moet inderdaad opnieuw gemaakt worden. Mij lijkt het handmatig doen voor nu de snelste optie |
Ben het eens met Marijn, een migratie voor data uit een tabel verwijderen is niet logisch. @indiePeeters Bedoel je handmatig seeden of handmatig de data uit de tabel verwijderen? |
Handmatig de bestaande records uit de Database verwijderen, met sql workbench of cli ofzo. De seeder zal ik vanavond even in elkaar zetten |
Gewoon een simpele SQL query draaien moet ook wel lukken denk ik. Dan maak ik wel eerst een backup ;) |
Dit nog gelukt? |
…vailable as env variable
@wouterbles zojuist de seeder in elkaar gezet en de env variabele naar de gehele url gezet |
Mooi! Heb je ook nog de API inlog gegevens van b2? Dan kan ik het even testen |
De photo album seeder werkte niet, die heb ik nog even gefixt. Verder lukt het uploaden van albums bij mij niet, de progress bar blijft op 0% staan. Ik zie geen errors in de console, en ook in de database gebeurt helemaal niets. |
Na veel te veel tijd heb ik eindelijk ontdekt waar het fout gaat sinds de overstap naar B2. Backblaze is zoals ze het zelf zeggen erg goedkoop door hun speciale server architectuur. Hierdoor kan het voorkomen dat je bij een upload een 500/503 response terugkrijgt. Dit is te interpreteren als, probeer het nog een keer, vaak lukt het dan de tweede of derde keer wel. Meer informatie op deze blogpost: https://www.backblaze.com/blog/b2-503-500-server-error/ Nu blijkt dat het package wat wij gebriuken "laravel-backblaze-b2" depend op "flysystem-backblaze" en deze weer depend op "backblaze-b2". Die laatste is de PHP SDK. Om te kijken of een van deze packages 500/503 errors afvangt en retried heb ik de source van al deze packages doorgekeken. Dit is niet het geval, bij een 500/503 error geeft "backblaze-b2" een exception, iets wat dus volgens de blogpost hierboven niet zou moeten gebeuren. Na even zoeken in de issues/PR's van de repo vond ik dit issue: gliterd/backblaze-b2#26. Naar mijn idee niet erg positief, een naar mijn idee legitiem issue wordt gesloten... Om het bovenstaande probleem in de package op te lossen heb ik in mijn lokale versie van "backblaze-b2" het bestand \Http\Client.php aangepast met de volgende code:
Voor zover ik het heb kunnen testen lost dit onze problemen op! Nu zijn er naar mijn idee twee dingen die moeten gebeuren:
UPDATE: UPDATE 2: |
Heel netjes uitgezocht @wouterbles! |
Dankje! Ik denk dat hij wel snel reageert, hij vroeg me om het openen van een PR. |
Nog een update: Ipv laravel filesystem wordt nu direct de php sdk gebruikt. Dit haalt wat abstractie weg, maar maakt het wel een stuk makkelijker om van php sdk te wisselen. Anders zouden we de twee bovenliggende packages ook moeten forken en aanpassen. Bovendien heeft dit deze php sdk ook cahcing zodat we niet onze API caps halen. Enige nadeel is dus dat hij de laatste twee commits nog niet heeft getagd in een release waardoor je een verouderde versie met bugs via composer binnen trekt. Ik heb daar een issue voor aangemaakt en hoop dat hij het fixt. Wat denken jullie verder over de wijziging van filesystem naar sdk? |
Ik stel voor om met deze PR even te wachten en kijken of we iets met Azure kunnen. Dat zou namelijk veel makkelijker zijn. |
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #73 +/- ##
============================================
- Coverage 19.79% 19.75% -0.04%
Complexity 620 620
============================================
Files 82 82
Lines 2117 2121 +4
============================================
Hits 419 419
- Misses 1698 1702 +4 ☔ View full report in Codecov by Sentry. |
Ook al gaan we misschien over op azure, heb hier toch nog even naar gekeken en alles werkt tot nu toe goed, behalve twee dingen:
|
Alles werkt! Moet nu naar een meeting dus commit het straks. |
Front end validatie fixen |
# Conflicts: # composer.lock # package-lock.json # resources/views/front-end/agenda.blade.php # resources/views/front-end/zekeringen.blade.php
Hier de pull request om S3 naar B2 te zetten
Alles verliep vrij soepel, alleen dat de library niet de url methode ondersteund. Waardoor het ophalen van de foto url niet kan. Aangezien ik zo snel mogelijk wil beginnen aan de ideal betalingen heb ik voor een snelle oplossing gekozen. Nu wordt url opgebouwd via string concat. Stel B2 kiest er later voor om hun server locatie te veranderen betekend dit dat er een regeltje in de code moet worden aangepast.