datasette-upload-dbs 0.5a0 bytter produksjonsbasen med ett POST-kall

«Du kan bygge ferske databaser i et miljø som GitHub Actions og bytte dem inn i produksjon så snart byggingen er ferdig.» Slik forklarer Simon Willison hva versjon 0.5a0 av datasette-upload-dbs er til for. Utvidelsen har eksistert en stund og lar deg sende en ny SQLite-fil til en Datasette-instans som allerede kjører, men den nye utgivelsen formaliserer opplastingen som et dokumentert API.

Selve kallet er vanlig curl mot /-/upload-dbs: databasen sendes som db=@content.db, navnet som db_name=content, og autentiseringen ligger i et Bearer-token i Authorization-headeren. Instansen fortsetter å kjøre mens den bytter base under seg selv.

«Den opplastede databasen lagres til en fil, verifiseres, og byttes så inn slik at /navn begynner å servere den nye» — Simon Willison, Simon Willison's Weblog

Rekkefølgen der er hele sikkerhetsnettet. En avbrutt eller ødelagt overføring rekker aldri å bli basen leserne dine treffer, fordi verifiseringen skjer før byttet og ikke etterpå. For deg som selvhoster betyr det at publiseringen av nytt innhold kan flyttes ut av serveren og inn i byggejobben: generer basen i CI, post den, og la Datasette servere den nye versjonen uten at du logger inn noe sted.

Versjonsnummeret sier likevel alfa. Bokstaven i 0.5a0 markerer en forhåndsutgivelse, så API-formen kan endre seg før den låses.

Hva bør du gjøre?

1. Lag et eget token til opplastingen i stedet for å gjenbruke et token med bredere rettigheter, siden endepunktet tar imot en hel database.
2. Flytt genereringen av SQLite-filen inn i byggejobben og la siste steg poste den til /-/upload-dbs.
3. Ta vare på forrige base så lenge API-et er merket alfa, så du har noe å rulle tilbake til.