Talk about innovative uses of gramps xml !

I see your point. As said, in 3.0 you will already get a warning on import of what happened. That is already useful.

I suppose you should do a feature request: Before import, give a some options on how to handle merge. We could then give some options when doing xml import, and one would be: merge-overwrite, and the other would be: consider input to be new data. The last would change all handles to new handles on import.

Could you do such a feature request. We have quite some requests about import at the moment, so I guess my next large work (when I finished rebuilding my house) will be to rewrite the xml importer as an Assistant application (like the 3.0 exporter).


2008/3/10, Michiel Nauta <>:
Hi Benny and others,

I like to come back to the issue I raised the previous weekend, now that
I have a test-case online (at
I understand that within Gramps the calculation of handles is such that
it is perfectly save to import data, also from others users of Gramps.
But I am thinking of a different use case: offer genealogical data as
gramps file, so that data entry becomes something close to
drag-drop/import. So what I am experimenting with is just a gramps-xml
file with a <?xsl-stylesheet type="text/xml"?> processing instruction at
the top. So the casual visitor sees some html-like presentation of the
data while the thorough visitor can see and copy the source. For an
example, I would like to point you to the above mentioned file which is
just a list of old farms with their location displayed on an old map
(use "view source" and/or shift-click on a circle/farm and choose "als
XML" to see the Gramps-xml (the latter doesn't work yet in Opera).)

Now your argument of low probability of coinciding handles isn't valid
any more, in view of all the villeins on the net who's joy it is to ruin
other peoples digital lives. They can just read the handles that are
used, set up a similar website, trick people to also import their foul
data and thus overwrite genuine content. (Yes, at this point I do wonder
  if I am going paranoid; if so just tell me.) If Gramps, on import,
stamps its own handles on the data (and what about the changetime?) then
this scenario couldn't happen.

Another benefit would be that now, the person/application offering
gramps-xml content needs to come with good handles. The
Oostdongeradeel.xml file mentioned above, doesn't, it is just a random
number under 1 million, which is enough for the limited set of
primary-objects that are in this file.


Benny Malengier schreef:

> Yes Michiel,
> that is the case, it has worked like that since I joined the project, but I
> heard somebody say it used to be different longer ago.
> Anyway, the changes of handles being the same is extremely low, as they are
> made behind the scenes in GRAMPS. So GRAMPS can use it as the _UID field in
> custom GEDCOM.
> So, in the future we could provide automatic merge on import based on equal
> handle, usefull for collaboration. You should hence not change handles made
> by GRAMPS, instead you should use the gramps id for whatever you want to do.
> At the moment however, merge-overwrite on import is a side-effect of how it
> is coded, and is not a supported thing, but I can see it supported in the
> future. Unfortunately the code gives no warning that it happened. In 3.0 I
> added a warning when merge happens, but it still 'just' happens and destroys
> much things you need to correct manually...
> Benny
> 2008/2/29, Michiel Nauta <>:
>> Hi,
>> I was thinking of putting some data on the net in Gramps-xml format. For
>> this I need to create handle attributes to tie all primary objects (or
>> whatever <person>, <source>, <event> etc are called) together. To my
>> surprise I find that the handles I created for the import XML file, are
>> the same as the handles that I find back when I export the imported
>> data. To my horror I find that if I import something with a handle that
>> is already in the database, the old data is overwritten. I have always
>> assumed that on import, new handles would be attached to the primary
>> objects. Are there no security implications for not doing so?
>> Sorry, I am still using Gramps 2.2.8 (I know I need to upgrade).
>> Michiel

This email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
Gramps-devel mailing list