Difference between revisions of "Nl:Gegevensbestandsformaten"

From Gramps
Jump to: navigation, search
(Versies)
(Familiestamboombeheerder)
Line 43: Line 43:
  
 
===Familiestamboombeheerder===
 
===Familiestamboombeheerder===
 +
[[Image:Dbmanager01.png|right|thumb|350px|Fig. 1 Familiestamboombeheerder]]
 +
 +
De nieuwe ''familiestamboombeheerder'' vervangt dus de {{man label|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 {{man button|Open}}-knop werd dus vervangen door een {{man button|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 deopend is, wordt dit aangegeven met een icoon naast de naam.
 +
  
De nieuwe ''familiestamboombeheerder'' vervangt dus de {{man label|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 {{man button|Open}}-knop werd dus vervangen door een {{man button|Familistamboom}}-knop. Wanneer u op deze knop klikt zal de familiestamboombeheerder geopend worden zoals hieronder wordt getoond.
 
  
[[Image:Dbmanager01.png|right|thumb|300px|Fig. 1 Familiestamboombeheerder]]
 
  
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 deopend is, wordt dit aangegeven met een icoon naast de naam.
 
  
 
==== Versies ====
 
==== Versies ====

Revision as of 18:37, 19 July 2008



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 deopend is, wordt dit aangegeven met een icoon naast de naam.



Versies

Fig 2 Beschikbare versies

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.

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.

Fig. 3 Selecteren van een te herstellen versie







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.

Fig 4 Herstelde versie





Versies kunnen verwijderd worden of herbenoemd worden.

Meerdere gebruikers

Fig 4 Meerder 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 5 Herstelknop

Mocht er zich ondanks alles zich toch een beschadiging van het gegevensbestand voordoen, zal de familistamboombeheerder dit bestand tonen in de lijst met een Fout icoon naast de bestandsnaam. Wordt dit bestand geslecteerd, 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 gamaakt 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.

Why no simultaneous access?

From time to time people want to use GRAMPS for collaborative research, and are then stopped as GRAMPS does not allow simultaneous access. That is, you can simultaneously access the database, but this typically results in corrupt data, destroying your database.

The motivation for this is the following:

  1. We would need a server/client infrastructure, like eg MySQL. However, this is also why MySQL is non-trivial for most users to maintain. We get into system startup files, gramps daemons running, and a whole mess of other stuff. And when you consider that probably under 5% of the users would be interested in something like this, we have to wonder about our return on investment. Is our time more valuable working on other stuff?
  2. Who to maintain this code? The core developers don't need this feature. Somebody should join the team to make this happen.

Technically, BSDDB can be made to work with a server environment. However, in GRAMPS we give the env.open() the DB_PRIVATE flag. The docs say:

DB_PRIVATE
Specify that the environment will only be accessed by a single process (although that process may be multithreaded). This flag has two effects on the Berkeley DB environment. First, all underlying data structures are allocated from per-process memory instead of from shared memory that is potentially accessible to more than a single process. Second, mutexes are only configured to work between threads.
This flag should not be specified if more than a single process is accessing the environment because it is likely to cause database corruption and unpredictable behavior. For example, if both a server application and the Berkeley DB utility db_stat are expected to access the environment, the DB_PRIVATE flag should not be specified.
Source: http://pybsddb.sourceforge.net/api_c/env_open.html

Note however that consecutive access from different places to the same underlying database will become possible with GRAMPS 3.0, so a collaboration based on time sharing (using different hours to input data in GRAMPS) will become possible.