From: J. S. <jul...@gm...> - 2008-08-24 07:36:55
|
Hi. Did anyone get this message? I got a message from SF reporting size problems and I am not sure if it finally got through. It is in the archives, but it seems broken there. Julio 2008/8/20 Julio Sánchez <jul...@gm...> > > Hi, > > Find it enclosed. There is a number of issues with it, some are the result of the port to 2.2, did not show up until now: > > There is some debugging code left that prints to stdout > Some lists are not handled yet, e.g. LDS ordinances. Look for TBC ("to be completed"). > There is considerable memory leakage (was not there in 2.0). I don't know the source > Repositories are not merged > There is a non-repeatable CPU loop somewhere, if you hit ^C while in it, it is in _change_person, but I have not found the cause. The same two people are merged correctly if you retry after killing GRAMPS. > The exact definition for the "is mergeable" condition is a matter of opinion. See is_mergeable_full in _Name.py that shows a pedantic comparison method that, in my opinion, is undesirable. I don't use it anymore, I use the current is_mergeable and I have just kept the other for illustration. > Correct merging requires that places and sources have been merged first. If persons are merged before that, event and source reference duplicates happen. Source and place merge should collapse those duplicates, it is useful even if places and sources can be merged on import, since this can fail if they are written differently in the existing database than in the imported file > Change times of merged objects are changed, even if no semantic change happened as a result of the merge. I'd rather keep it unchanged. > > Hope it helps, > > Julio > > > > 2008/8/18 Benny Malengier <ben...@gm...> >> >> Sorry, long weekend here. >> To send it, best is this devel list, or if too large, directly to some devels including myself. I'd start a PEP, and attach the file as example code in the 2.2.x branch >> >> Benny >> >> 2008/8/14 Julio Sánchez <jul...@gm...> >>> >>> Where should I send it? >>> >>> Julio >>> >>> 2008/8/14 Benny Malengier <ben...@gm...> >>>> >>>> Julio, >>>> >>>> I think everybody would be most interested to see a diff with your changes to hack in merging in 2.2.x >>>> I know we talked much about it in different threads about the how, however, I don't recall ever seeing any code. The most comlex matter is deciding how to update references (decide to merge or add), but you should have that in place. >>>> >>>> As to the GUI part, if we split the functionality so it can be used CLI and GUI, it should not be overly slow. And anyway, I don't think people mind an import is slow, as long as they get feedback while the import happens and it doesn't hang. >>>> >>>> Benny >>>> >>>> 2008/8/14 Julio Sánchez <jul...@gm...> >>>>> >>>>> Hi, >>>>> >>>>> I have forward-ported my merging changes to 2.2 (I do not run 3.0 and I won't for a while, I'll probably move my scratch databases to 3.0 but will keep databases I treasure on 2.2 for now). When I do that, a lot of the merging fixes will be there. >>>>> >>>>> In the meantime, if you want to move forward, ask me for those fixes. They merge people layer by layer. For instance, when you merge two people, their event lists are compared. Events that are compatible are merged, others are added. Merging compatible events means, for instance, comparing their source reference list and merging them. Compatible references are merged, incompatible references are added. And so on. I think it is a good starting point. >>>>> >>>>> Problem with using this for merging while importing is that it might be slow. Merging from the graphical interface is slow, maybe because of the cost of recomputing the view and that might not be a problem while importing because no view refreshing would happen. I had thought of doing something on the fly while importing, but it is hard. >>>>> >>>>> Regards, >>>>> >>>>> Julio >>>>> >>>>> >>>>> 2008/8/14 Benny Malengier <ben...@gm...> >>>>>> >>>>>> >>>>>> 2008/8/13 Brian Matherly <br...@gr...> >>>>>>> >>>>>>> > 3/I think your ambitious approach is good. Perhaps Brian >>>>>>> > (project leader) >>>>>>> > can tune in. I know Don always thought merge to be an >>>>>>> > almost impossible to >>>>>>> > achieve goal. With more and more collaborative web tools, >>>>>>> > it looks like it >>>>>>> > is needed however (in my opinion). >>>>>>> >>>>>>> It has been interesting to watch you all go though the same thought process we have gone through a dozen times before. It always happens this way. A user says "Hey, Gramps didn't act the way I expected. Why didn't you guys build Gramps to work properly". And then when we ask them to elaborate on exactly how they expect Gramps to behave, they go through this whole thought process only to eventually say "Hmmm, I guess it isn't as obvious as I thought". >>>>>> >>>>>> we should not discourage people. This is a mail on devel list from a developer, not user list, so it is worth restating the problem. >>>>>> Anyway, some of the work will have to be done anyway: rechecking merge of objects inside of GRAMPS and doing it for all objects (eg notes cannot be merged at the moment), multiple merge of objects inside GRAMPS (so more than two, often requested), ... >>>>>> If those are tackled, why would merge on import be so hard? In the end, it comes down to importing everything, identifying what probably is the same (easy actually, same handle, same _UID), then calling the merge tools as manual merge of objects already does. >>>>>> We should not make this problem more complicated than it is. It only needs people who want to do it, as it will take a part of the year of your free coding time. However, starting with the above pieces, one can have immediate return of ones efforts, even if the end goal (real import merge) is not achieved. >>>>>> >>>>>>> >>>>>>> I'm not opposed to adding merging capabilities, but I am opposed to thoughtlessly hacking it in. Gramps behavior needs to be deterministic in all cases. And it should error on the side of caution when making decisions about people's data. >>>>>>> >>>>>>> The biggest problem you are going to have with merging is that people will not be able to agree on the proper behavior. Some people will want missing objects left in while others will want them automatically removed. The same goes for relationships. >>>>>> >>>>>> My two cents is that people will want missing objects left in. One cannot expect GRAMPS to resolve issues and remove no longer correct relationships. >>>>>> >>>>>>> >>>>>>> If you guys are *serious* about adding merging capabilities to Gramps, I suggest you start a page on the wiki. This new page should clearly state the use cases that require these capabilities. For each use case, state the user's goals, needs, and concerns. Then, let's build consensus around the wiki page before anyone runs off and writes a bunch of code. >>>>>>> >>>>>>> Thanks everyone for the healthy discussion. I'm sure that if we keep working on this, we will come up with a great solution. >>>>>>> >>>>>>> ~Brian >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------- >>>>>> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge >>>>>> Build the coolest Linux based applications with Moblin SDK & win great prizes >>>>>> Grand prize is a trip for two to an Open Source event anywhere in the world >>>>>> http://moblin-contest.org/redirect.php?banner_id=100&url=/ >>>>>> _______________________________________________ >>>>>> Gramps-devel mailing list >>>>>> Gra...@li... >>>>>> https://lists.sourceforge.net/lists/listinfo/gramps-devel >>>>>> >>>>> >>>> >>> >> > |