On Tue, 24 Jun 2003, Doug had this to say:
>Perhaps this should be on the -devel list but anyway...
And I'm moving it there... :)
>couldn't it be as simple as adding a flag to the xml dataset for each
>record. The flag would be set to <off> by default.
No. :)
>When a remote dataset was being accessed, gramps would set the flag for a
>record being edited to <on> and save the dataset immediately. Whenever
So, every time you or your mother or your brother edit or view a person,
you're going to re-save the database? Over the internet? This may be
somewhat reasonable for a SMALL database, but for anything approaching
even 1000 names, this becomes a major I/O load. It would also
significantly affect (negatively) gramps' performance.
>It wouldn't be a perfect solution or a completely foolproof solution, but
>it the chances of people editing the same record in a several hundred or
>more name dataset at exactly the same time is pretty remote anyway!
But! The issue is not editing the SAME person at the same time, it's now
an issue of editing ANY two people at the same time because the database
has to be accessed to be saved. You run into MAJOR issues if two people
even come close to saving/editing at the same time---esp. if you're doing
this via remote access.
Then, we have the issue that Mom is editing information about Aunt Betty,
so we save the database with Betty's flag set. But then you add
the newborn son of Uncle Dave. You then save the file. What happens when
Mom is done? If she saves her work, your work is lost. So, she has to
reread the database before saving it, effective doubling our already
intense I/O load. But rereading may affect the information she has---or
rather, where her modified info goes in the XML file.
These are just a couple of issues that I can think of off the top of my
head. I'm sure there are other problems as well without doing true file
locking.
The Truly Right Answer (IMHonestO) for multiple researchers is to use a
real database, where the cells are locked as they are edited, rather than
the simple but elegant XML format. But, alas, this isn't in the
near-future of gramps. :(
Cheers,
-Don
________________________________________________
Donald A. Peterson | dpeterson@...
Ph.D. Research Associate |
Dept. of Chemistry | PH: (541) 737-7079
Oregon St. University | FAX: (541) 737-0480
------------------------------------------------

Thread view

On Tue, 24 Jun 2003, Doug had this to say:
>Perhaps this should be on the -devel list but anyway...
And I'm moving it there... :)
>couldn't it be as simple as adding a flag to the xml dataset for each
>record. The flag would be set to <off> by default.
No. :)
>When a remote dataset was being accessed, gramps would set the flag for a
>record being edited to <on> and save the dataset immediately. Whenever
So, every time you or your mother or your brother edit or view a person,
you're going to re-save the database? Over the internet? This may be
somewhat reasonable for a SMALL database, but for anything approaching
even 1000 names, this becomes a major I/O load. It would also
significantly affect (negatively) gramps' performance.
>It wouldn't be a perfect solution or a completely foolproof solution, but
>it the chances of people editing the same record in a several hundred or
>more name dataset at exactly the same time is pretty remote anyway!
But! The issue is not editing the SAME person at the same time, it's now
an issue of editing ANY two people at the same time because the database
has to be accessed to be saved. You run into MAJOR issues if two people
even come close to saving/editing at the same time---esp. if you're doing
this via remote access.
Then, we have the issue that Mom is editing information about Aunt Betty,
so we save the database with Betty's flag set. But then you add
the newborn son of Uncle Dave. You then save the file. What happens when
Mom is done? If she saves her work, your work is lost. So, she has to
reread the database before saving it, effective doubling our already
intense I/O load. But rereading may affect the information she has---or
rather, where her modified info goes in the XML file.
These are just a couple of issues that I can think of off the top of my
head. I'm sure there are other problems as well without doing true file
locking.
The Truly Right Answer (IMHonestO) for multiple researchers is to use a
real database, where the cells are locked as they are edited, rather than
the simple but elegant XML format. But, alas, this isn't in the
near-future of gramps. :(
Cheers,
-Don
________________________________________________
Donald A. Peterson | dpeterson@...
Ph.D. Research Associate |
Dept. of Chemistry | PH: (541) 737-7079
Oregon St. University | FAX: (541) 737-0480
------------------------------------------------