Som svar: bra! Som semaforprincip: diskutabel - men betydligt bättre än ingen. Vore inte utnyttjande av faciliteterna i WAL (Write Ahead Logging) att föredra? (SQLite >= 3.7 förmodas)
Borde möjlighet att exekvera Disgen i 'read-only' läge finnas?
Som svar: bra! Som semaforprincip: diskutabel - men betydligt bättre än ingen. Vore inte utnyttjande av faciliteterna i WAL (Write Ahead Logging) att föredra? (SQLite >= 3.7 förmodas)
Borde möjlighet att exekvera Disgen i 'read-only' läge finnas?
Inser inte riktigt hur det skulle påverka semaforprincipen som sådan, det gör det väl knappast? Men om du menar att Disgen borde klara samtidiga användare så är det rätt många andra saker i koden som effektivt förhindrar detta, i alla fall i dagsläget. Det är i alla fall inte något som enbart kan lösas på databasnivån.
Det finns möjlighet att köra disgen readonly men det fungerar bara nästan. Om man in den situationen jag nämnde väljer att inte bryta låset så hamnar Disgen i readonly-läge men man får vara beredd på en och annan krasch. Det ska vi nog kunna reparera med tiden.
Även 8.2 fanns faktiskt i en särskild läsversion, men den fick aldrig någon spridning. Där var alla spärrar gjorda i användargränssnittet och resultatet blev inte så värst bra.
Vice ordförande (2025) & Disgenutvecklare.
För att den aktuella semaforprincipen skulle ha varit säker, hade läsning och skrivning av tabellraden behövt vara en atomär operation (jämför 'Compare-and-swap' eller 'Test-and-set').
Å andra sidan används ju Disgen inte - som tur är - i några säkerhetskritiska sammanhang.
Säkerhetskritisk släktforskning, ja det hade ju varit något.
Nu finns det i och för sig ytterligare lås som förhindrar att två instanser av Disgen öppnar samma datamapp, och där används existensen av en namnad mutex som lås. Det blir vattentätt så länge man är på samma maskin. Jag tror dessa mekanismer tillsammans blir tillräckligt bra i förhållande till vad vi vill uppnå...
Vice ordförande (2025) & Disgenutvecklare.