Re: [Gramps-users] [Gramps-devel] [Gramps-windows] Database Loading Issue

[Alex R. <sh...@gr...>]

Wow, so many emails! I probably should be the one to call
for a stop to this cross-posting madness. Please let's confine
this thread from now on to gramps-devel and let this message be
the last one to go to all three lists.

On Thu, 2006-09-14 at 09:09 -0400, Gerald Britton wrote:
> My gramps DB *is* backed up. However, from 2.1 on, if I understand
> this thread correctly, restoring that DB from backup will not
> guarantee that it can be read by gramps.

I think you misread what Don was suggesting. He suggested that
you backup your ~/.gramps directory *along* with the db backup.
The ~/.gramps directory holds some gramps configuration stuff
plus the environment dir. If you grdb is saved and your ~/.gramps
is saved, then when you restore both you should have no problem
opening the grdb in that same environment.

>   Alex even said that if I
> were just to create a new user  on the same system and try to read the
> database, it might fail!
>=20
> As for integrity, I have yet to have a problem with data integrity
> with gramps but it looks like I *will* have one as soon as I move to
> 2.1.  He said:
>=20
> "Create a new user account, log into it and try opening the
> grdb from 2.1.x. Depending on how much editing you have done
> in grdb before closing, you may or may not open it. It also
> may depend on the libdb version and python built, that vary
> across the distros."
>=20
> If I'm understanding what I'm reading, 2.1 will remove my ability to:
>=20
> 1. upgrade my HD and copy my gramps files from my old HD to a new one.
> 2. upgrade or change my distro (unless the python levels match, I suppose=
)
> 3. move to another platform (Windows, Mac, whatever)
> 4. rsync, scp, zip/email/unzip, my gramps db to/from another machine
> 5. backup my database to CD/USB drive, whatever and later restore it
> -- possibly to another machine or HD
>=20
> If any of these items is true, my data integrity issues will increase
> significantly with 2.1

Please don't mix up the two concepts:
1. When you have a crash in gramps, you can restart gramps
right away and have your data intact. At most you will have
the last edit not committed. No damage done to the data.
2. When you take your file some place else, using tools
other than gramps, it may fail to open.

1 is data integrity. 2 is portability. I agree that one may
call 2 as archiving, backup, etc., but I think it's clear what
is meant by integrity at least.


Now to the doom and gloom scenario: the grdb created in 2.1 cannot
be easily opened by gramps if taken out of environment. Note that
it's *only* GRDB format. XML data is fine. As many pointed out,
XML also takes far less space. It is human readable, well documented,
and is definitely a preferred format for archiving, backups,
transferring to other machines, etc.


If you are so insistent on not doing an XML export for these purposes
(or just doing it as a prudent data safety step, every now and then)
then may I suggest you just use XML natively. Create your databases
in XML format, then open (not import, but a true open), edit, and exit.
On opening, you will have to wait for a somewhat long parsing process.
The whole dataset will be in memory, so depending on your data size
it may or may not be fast enough. On exit the data is saved in XML
again. Since you don't care about the performance then you should be
fine. You can rely on your existing backup tools, the XML files
(.gramps) are completely sufficient and there's no data loss.


But if you find this a bit too slow or memory-inefficient, maybe you
can adopt this scenario:
1. Create data in grdb
2. Work with it.
3. Export into XML e.g. every day or every week, depending
on how frequently you edit. GRAMPS can do the command
line mode (with DISPLAY set, though) so it can be scripted.

An export is usually a breeze. Try exporting your data set into XML,
see how bad it is. Import is much worse, but will you only need import
when you move/reinstall/email the data. Otherwise you will continue
to work with the grdb, which is huge but very performant.


So the more I think about it, the more this problem seems like
the need for knowing the things, not really something unsolvable.
I wish this was not a problem. I wish we had python2.5 right now.
Oh well...

Alex

P.S. For those who back up, there is yet another way to make grdb
portable: db_dump and db_load (on my systems they are db4.3_dump
and db4.3_load). If you do it on a database within the environment
(that is, when backing up), the dumping to text and then loading
from text should get rid of the environment coupling. I read in the
docs that it should be that way, but have not tested it myself.
So try it before taking it to the bank.

--=20
Alexander Roitman   http://www.gramps-project.org