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 <m.d.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
> > made behind the scenes in GRAMPS. So GRAMPS can use it as the _UID field
> > custom GEDCOM.
> > So, in the future we could provide automatic merge on import based on
> > handle, usefull for collaboration. You should hence not change handles
> > by GRAMPS, instead you should use the gramps id for whatever you want to
> > At the moment however, merge-overwrite on import is a side-effect of how
> > is coded, and is not a supported thing, but I can see it supported in
> > future. Unfortunately the code gives no warning that it happened. In 3.0I
> > added a warning when merge happens, but it still 'just' happens and
> > much things you need to correct manually...
> > Benny
> > 2008/2/29, Michiel Nauta <m.d.nauta@...>:
> >> Hi,
> >> I was thinking of putting some data on the net in Gramps-xml format.
> >> 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 SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> Gramps-devel mailing list