Nl:Gegevensbestandsformaten

From Gramps

Geschiedenis

Het standaard GRAMPS-dataformaat is in de loop van de tijd sterk veranderd. Elke belangrijke formaatsverandering ging gewoonlijk gepaard met verhoging van het een hoofdversienummer.

GRAMPS 1.0 en nog vroeger

GRAMPS 1.0 gebruikte het XML-formaat als standaard. Dit is een volledig omzetbaar formaat en het formaat kan gemakkelijk door mensen en computers gelezen worden. Maar het heeft twee belangrijke nadelen:

  • Traag bij het laden en opslaan. Het volledige bestand moet vertaald worden om gegevens op te halen en dit vertaalproces is niet erg snel. Ook bij het opneiuw opslaan van gegevens, moet het volledige bestand weggeschreven worden. Mensen die grotegegevensbestanden verwerkten (met duizend en meer personen) vonden dan ook dat dt XML-formaat eigenlijk veel te traag was en onbruikbaar.
  • Gebruikt zeer veel geheugen. Het XML-formaat vereist dat alle gegevens in het geheugen moeten gestockeerd worden. Grote gegevensbestanden gebruiken zo het gehele beschikbare systeemgeheugen en brachten het systeem virtueel tot stilstand.

GRAMPS 2.0

Om de capaciteitsproblemen op te lossen ging GRAMPS 2.0 over naar een Berkeley-gegevensbestandformaat. Zo een bestand heeft de .grdb-extensie. Alle gegevensinformatie werd opgeslagen in dit bestand. Beide vorige nadelen werden voorkomen, zowel de trage laad/opslag tijden als het geheugenverbruik. Door gebruik te maken van een echte database backend worden enkel die gegevens in het geheugen geladen die nodig zijn.

Het grdb-formaat was voor GRAMPS een zeer belangrijke stap voorwaarts. Maar dit formaat is gevoelig voor beschadigingen van het gegevensbestand. Omdat gegevensopslag niet atomair was (alle verwante veranderingen in één keer opslaan), kon het gebeuren dat de gegevens beschadigdwerden als zich een fout voordeed wanneer een verandering gebeurde.

GRAMPS 2.2

GRAMPS 2.2 startte met de transactiemogelijkheden van het Berkeley-databasesysteem. Deze eigenschap liet toe om alle verwante gegevens in één maal op te slaan. Indien er zich nu een fout zou voordoen op het moment dat de gegevens worden opgeslagen, blijft het gegevensbestand toch intact. Ofwel worden alle veranderingen opgeslagen ofwel geen enkele.

Maar ook deze methode heeft zijn nadelen. Eén enkel (het .grdb-bestand) bestand volstond niet langer. Er was een omgevings-map nodig om de log-bestanden van de verschillende transacties op te slaan.

Er was een plaats nodig om deze bestanden te bewaren, zodat de gebruiker ze niet kon wissen. Er werd geopteerd om een ~/.gramps-map voor de omgevingsmap te gebruiken. En de logbestanden werden opgeslagen met een pad dat gelijk was aan het oorspronkelijke.grdb-bestand.

Dit systeem bleek zeer goed te werken, zolang het bestand nooit werd verplaatst. Als de gebruiker het bestand herbenoemt, een reservekopie herstelt of het bestand verplaatst naar een andere computer, werkt het bestand niet meer, omdat er geen verband meer bestaat tussen de logbestanden die opgeslagen werden onder de ~/.gramps-map.

GRAMPS 3.0

Een nieuwe methode werd gebruikt voor GRAMPS 3.0. De Berkeley-database wordt nog steeds gebruikt, maar de gebruiker ziet het bestand niet meer. In plaats van de echte database te openen, opent de gebruiker nu een symbolisch bestandsnaam. Deze naam is geplaatst in een map die zich in de map ~/.gramps bevindt en die ook alle benodigde gegevensbestanden bevat.

Omdat nu alle bestanden zich in dezelfde map bevinden, kunnen gevorderde gebruikers een reservekopie maken van de hele map en zo alle gegevens opslaan. Nieuwe gebruikers die nog niet zo ervaren zijn met het Linux bestandssysteem moeten zich geen zorgen maken over het al of niet treug vnden van hun gegevensbestand omdat een nieuwe familiestamboombeheerder de oude Open bestand-dialoog vervangt.

Familiestamboombeheerder

Fig. 1 Familiestamboombeheerder

De nieuwe familiestamboombeheerder vervangt dus de Open bestand-dialoog. Versie 3.0 werkt niet met bestanden, maar met familiestambomen. Omdat dit geen echt bestand is, is er ook geen dialoog om ee bestand te openen.




De Open-knop werd dus vervangen door een Familiestamboom-knop. Wanneer u op deze knop klikt zal de familiestamboombeheerder geopend worden zoals hieronder wordt getoond.


Deze beheerder laat de gebruiker toe om een nieuw gegevnsbestand aan te maken, een oud bestand te herbenoemen, een gegevensbestand te verwijderen of een gegevnsbestand op te laden. Alle gegevensbestanden verschijnen in de lijst zodat de gebruiker zich geen zorgen meer moet aken van waar die gegevensbestanden zich nu juist bevinden.

Wanneer een bestand geopend is, wordt dit aangegeven met een icoon naast de naam.



Versies

Fig 2 Beschikbare versies
Fig. 3 Selecteren van een te herstellen versie

Indien er een RCS : revisiecontrolesysteem op uw systeem is geïnstalleerd, kan GRAMPS bepaalde versies va uw gegevensbestand archiveren. Om een bepaalde versie op te slaan, opent u de familiestamboombeheerder en selecteert u een geopende gegevensbestand.

Door eenvoudig op de Archiveren-knop te klikken zal de huidige versie opgeslagen worden in het revisiesysteem.

Indien een gegevensbestand één of meerdere gearchiveerde versies heeft, zullen de bestanden als een boom worden voorgesteld met als takken de beschikbare versies.






In dit voorbeeld heeft de familiestamboom Gramps Example twee versies die opgeslagen werden. Deze versies zijn opgeslagen momentopnames van de inhoud van uw gegevensbestand.

Fig 4 Herstelde versie

Het wezenlijke voordeel van het opslaan van verschillende versies is dat u steeds terug kunt gaan naar een vorig opgeslagen moment. Om een versie opnieuw te herstellen, selecteert u eerst de gewenste versie en klikt u op de Herstellen knop.







GRAMPS zal de te herstellen versie in een nieuw gegevensbestand laden. De naam van dit bestand zal gebaseerd zijn op het originele bastand en de revisienaam.






Versies kunnen verwijderd worden of herbenoemd worden.

Meerdere gebruikers

Fig 5 Meerdere gebruikers

In tegenstelling met de vorige versies, ondersteunt GRAMPS 3.x een beperkte vorm van delen van gegevensbestanden.



Meerdere gebruikers kunnen hetzelfde bestand aanpassen, maar niet op hetzelfde tijdstip.

De familiestamboombeheerder geeft immers aan welk bestand er geopend is op een bepaald moment voor een bepaalde gebruiker.




Dit betekent ook dat u dan dit geopend bestand niet opnieuw kan openen.



U kunt het bestand eerst bewerken nadat de andere gebruiker het bestand gesloten heeft.

Een beschadigd bestand herstellen

Fig 6 Herstelknop



Mocht er zich ondanks alles zich toch een beschadiging van het gegevensbestand voordoen, zal de familiestamboombeheerder dit bestand tonen in de lijst met een Fout icoon naast de bestandsnaam.







Wordt dit bestand geselecteerd, dan wordt een Herstel knop getoond. Door op de Herstel knop te klikken wordt het bestand hersteld vanuit de reservekopie die automatisch bij het verlaten van het programma gemaakt worden.

Automatische reservekopie

Om het probleem van beschadigde bestanden te vermijden, genereert GRAMPS 3.x een reservekopie telkens het programma gestopt wordt en er gegevens werden veranderd. In tegenstelling tot de 2.2 versie, zijn deze bestanden niet in het XML-formaat. De nieuwere reservekopieën zijn een dump van de database-tabellen. Dit laat toe om de gegevens zeer snel op te kunnen slaan. Er is een reservekopie voor iedere tabel. Deze reservekopieën zijn voor de gebruiker niet zichtbaar en worden in de map van het gegevensbestand opgeslagen.

Waarom geen simultane toegang?

Soms willen mensen GRAMPS gebruiken voor gemeenschappelijk onderzoek en stellen dan vast dat GRAMPS geen simultane toegang toe laat. Eigenlijk is simultane toegang mogelijk, maar dit zal meestal resulteren in beschadigde gegevens en het gegevensbestand vernietigen.

Hier is de motivatie:

  1. We willen eigenlijk een server/client infrastructuur, zoals bv. MySQL.

Maar dit is dan ook de reden waarom MySQL voor de meeste gebruikers niet vanzelfsprekend is om te onderhouden. Zo hebben we systeemopstartbestanden nodig, gramps-daemons die moeten draaien en een boel andere dingen waar aan gedacht moet worden. Wanneer u bovendien in overweging neemt dat minder dan 5% van de gebruikers eigenlijk baat bij dit systeem heeft, stellen we ons vragen over de efficiëntie van het ontwikkelen van zulke systemen. Misschien is het nuttiger onze tijd aan andere dingen te spenderen?

  1. Wie zal de programmacode onderhouden? De hoofdontwikkelaars hebben geen behoefte aan zulk systeem. Dus zal iemand met de nodige kennis en ervaring zijn diensten ter beschikking moeten stellen van het ontwikkelingsteam.

Technisch gezien kan BSDDB met een server-omgeving werken. Maar in GRAMPS geven we de env.open() het kenmerk DB_PRIVATE flag mee. De documentatie zegt hierover:

DB_PRIVATE
Geeft aan dat de omgeving slechts door één proces benaderd kan worden (dit proces kan echter multithreaded zijn). Deze vlag heeft twee uitwerkingen op de Berkely DB-omgeving. Ten eerste zullen alle onderliggende gegevensstructuren geheugen toegewezen krijgen per proces i.p.v. via een gedeeld geheugen dat mogelijk bereikbaar is via meerdere processen.

Ten tweede mutexes worden enkel verondersteld te werken tussen threads.

Deze vlag zal niet opgegeven worden indien meerdere processen de omgeving willen benaderen omdat dit gewoonlijk bescheaigingen veroorzaakt aan de gegevensbestanden en een onvoorspelbaar gedrag. Als een server-toepassing en de Berkeley DB db_stat-voorziening samen de omgeving benaderen mag de DB_PRIVATE-vlag niet opgegeven worden.
Bron: DB_ENV->open

Merk echter op dat achtereenvolgende toegang vanaf verschillende plaatsen tot hetzelfde onderliggend gegevensbestand wel mogelijk is in GRAMPS 3.0. Zodoende is samenwerking gebaseerd op tijdsverdeling (timesharing): gebruik van verschillende uren van gegevensbewerkingen door verschillende gebruikers, wel mogelijk.