From: <sk...@ac...> - 2005-10-07 08:51:25
|
In the current CVS version, and empty string in the 'Death Date' string is still parsed as an empty date, resulting in 'd. ' being printed in the family view and in reports ('born on <date>, died <empty string>'). The error persists both in en_US and sv_SE locale. Stefan |
From: Julio S. <jul...@gm...> - 2005-10-10 14:30:51
|
2005/10/7, Stefan Bj=F6rk <sk...@ac...>: > In the current CVS version, and empty string in the 'Death Date' string > is still parsed as an empty date, resulting in 'd. ' being printed in > the family view and in reports ('born on <date>, died <empty string>'). Apparently this problem is more general. It happens on birth dates as well. Worse of all, it breaks probably_alive in computation since the existance of the bogus, empty, death event is taken as proof of a previous death. After opening NameEdit on a person that had no death event and attempting to Cancel, GRAMPS will complain that it has unsaved changes. Accepting the changes will create empty death (and birth if it was not there before) events that cannot be removed later and that create varied problems, including the one you mentioned. The problem is probably due to the recent changes in DateParser conflicting with the changes made to EditPerson late June.=20 Unfortunately, even if the date problem were to be solved, it seems that the empty death event cannot be deleted. Anyway, the date editor is very unpredictable in its behaviour, it is very difficult to remove the text describing a date. Changing it to another string is relatively easy. Removing it altogether requires non-obvious gymnastics. And, of course, it does not remove the date object nor the birth or death event objects. Exporting the database to XML, these dates appear as '????': <event type=3D"Death"> <dateval val=3D"????"/> </event> With respect to birth and date events, they should have simple and consistent semantics: either they may exist even if empty (and every piece of code, like probably_alive, has to learn about this) or they have to be removed autmoatically if left empty. Of course, empty means no date and no place but no notes, sources, witnesses or media objects either. Julio |
From: Alex R. <sh...@gr...> - 2005-10-14 00:55:47
|
Julio, On Mon, 2005-10-10 at 16:30 +0200, Julio Sanchez wrote: > 2005/10/7, Stefan Bj=C3=B6rk <sk...@ac...>: > > In the current CVS version, and empty string in the 'Death Date' string > > is still parsed as an empty date, resulting in 'd. ' being printed in > > the family view and in reports ('born on <date>, died <empty string>'). >=20 > Apparently this problem is more general. It happens on birth dates as > well. Worse of all, it breaks probably_alive in computation since the > existance of the bogus, empty, death event is taken as proof of a > previous death. I agree that we need to fix this. > After opening NameEdit on a person that had no death > event and attempting to Cancel, GRAMPS will complain that it has > unsaved changes. Accepting the changes will create empty death (and > birth if it was not there before) events that cannot be removed later > and that create varied problems, including the one you mentioned. I cannot reproduce this with current CVS. If you can, please let me know how to. If this can be done from scratch with e.g. a single newly created person or similar, it would be great. Or send me a short XML if creating from scratch does not expose it. > The problem is probably due to the recent changes in DateParser > conflicting with the changes made to EditPerson late June.=20 > Unfortunately, even if the date problem were to be solved, it seems > that the empty death event cannot be deleted. This is true. Actually, no events can be deleted in 2.0.x, empty or not. They're simply unlinked (in the event tab) or date emptied (birth/death). This is because they're primary objects in 2.0.x, but the interface does not support it yet. This will not be a problem for 2.2. for which there's an event view. For 2.0.x we will have to make a script deleting empty and/or unlinked events. An event that is not linked to any person or family is as good as absent in 2.0. A completely empty event is also just a stupid placeholder and can be safely deleted. We probably should also make this routine a part of Check and Repair plugin. That said, in 2.0 the empty events other than Birth and Death should not bring us any troubles. They are only wasting space, but should be unlinked from any person/family. It's only the empty Birth/Death that bring problems. > Anyway, the date editor is very unpredictable in its behaviour, it is > very difficult to remove the text describing a date. Changing it to > another string is relatively easy. Removing it altogether requires > non-obvious gymnastics.=20 I will look into making sure that birth and death dates are set to empty if the text entry field is emptied by the user.=20 > And, of course, it does not remove the date > object nor the birth or death event objects. Exporting the database > to XML, these dates appear as '????': >=20 > <event type=3D"Death"> > <dateval val=3D"????"/> > </event> Actually, I fixed the date part in XML just now, but it is not fixing the problem, just making it harder to debug :-) The empty dates will not be written to the XML at all. The empty events, however, will. Probably we should do away with that, but it would be nice to fix this at the root, not only in the export. > With respect to birth and date events, they should have simple and > consistent semantics: either they may exist even if empty (and every > piece of code, like probably_alive, has to learn about this) or they > have to be removed autmoatically if left empty. Of course, empty > means no date and no place but no notes, sources, witnesses or media > objects either. We probably should remove empty events automatically in 2.0. I cannot see any reason in keeping them for any purpose. Should we just do it? Alex --=20 Alexander Roitman http://www.gramps-project.org |
From: Alex R. <sh...@gr...> - 2005-10-14 05:10:18
|
Julio, On Thu, 2005-10-13 at 17:55 -0700, Alex Roitman wrote: > > Apparently this problem is more general. It happens on birth dates as > > well. Worse of all, it breaks probably_alive in computation since the > > existance of the bogus, empty, death event is taken as proof of a > > previous death. >=20 > I agree that we need to fix this. It seems that Don has fixed it a few days ago. I'll go ahead and clean up the XML writer to skip empty events. For the 2.0.9 we will come up with the database upgrade path to delete empty and unlinked events from GRDB files. Alex --=20 Alexander Roitman http://www.gramps-project.org |
From: Julio S. <jul...@gm...> - 2005-10-14 07:55:58
|
Alex, Sorry, I did not see your answer until now. 2005/10/14, Alex Roitman <sh...@gr...>: > > It seems that Don has fixed it a few days ago. I'll go ahead and > clean up the XML writer to skip empty events. For the 2.0.9 > we will come up with the database upgrade path to delete empty > and unlinked events from GRDB files. This means we will have to export to XML and recreate? Did I get it right? Is this always a safe thing to do? I did it a couple of weeks ago and it worked, I think. The only strange thing was the given name-based sex-guessing, it started from scratch after the reload. Regards, Julio |
From: <tie...@fr...> - 2005-10-14 08:19:13
|
Hello, As you might have noticed my contributions to French translation have bee= n inexistant this past weeks. As we say in French "j'attends un heureux =E9v=E8nement" (a baby is comin= g). That's why I won't have so much time to come back in the next future, so feel fr= ee to remove me from the translators list. I also canceled my suscription to gramps mailing lists. Matthieu |
From: Julio S. <jul...@gm...> - 2005-10-14 07:51:33
|
Alex, 2005/10/14, Alex Roitman <sh...@gr...>: > Julio, > > On Mon, 2005-10-10 at 16:30 +0200, Julio Sanchez wrote: > > After opening NameEdit on a person that had no death > > event and attempting to Cancel, GRAMPS will complain that it has > > unsaved changes. Accepting the changes will create empty death (and > > birth if it was not there before) events that cannot be removed later > > and that create varied problems, including the one you mentioned. > > I cannot reproduce this with current CVS. If you can, please let > me know how to. If this can be done from scratch with e.g. a single > newly created person or similar, it would be great. Or send > me a short XML if creating from scratch does not expose it. This has been fixed by Don through his recent changes. Now the empty event is not created anymore. > I will look into making sure that birth and death dates are set to > empty if the text entry field is emptied by the user. I think this is fixed already as well. Its behaviour now is more predictab= le. > We probably should remove empty events automatically in 2.0. > I cannot see any reason in keeping them for any purpose. > Should we just do it? Very possibly. But please notice that Event.is_empty() may return true even in the presence of witnesses, notes, source references and/or gallery objects. I hate it when data disappears for no reason. Anyway, how do we clean our current databases for now? Regards, Julio |
From: Alex R. <sh...@gr...> - 2005-10-14 08:08:18
|
On Fri, 2005-10-14 at 09:55 +0200, Julio Sanchez wrote: > 2005/10/14, Alex Roitman <sh...@gr...>: > > > > It seems that Don has fixed it a few days ago. I'll go ahead and > > clean up the XML writer to skip empty events. For the 2.0.9 > > we will come up with the database upgrade path to delete empty > > and unlinked events from GRDB files. >=20 > This means we will have to export to XML and recreate? Did I get it righ= t? No, what I meant was the upgrade function that will run automatically on opening the database if the database version is lower than what will ship with 2.0.9. We have already done 6 or 7 of those, so it's nothing new. New gramps can read grdb from any older version, since we keep track of all upgrades needed. It just might take long to open database created with 2.0.0 in 2.0.9. But it's almost the same between 2.0.0 and 2.0.8 :-) > Is this always a safe thing to do? I did it a couple of weeks ago and > it worked, I think. The only strange thing was the given name-based > sex-guessing, it started from scratch after the reload. We thought it was, but today I found out that "estimated" and "calculated" were missing from XML import/export. This will be fixed in 2.0.9 (already fixed in CVS). Alex --=20 Alexander Roitman http://www.gramps-project.org |
From: Julio S. <jul...@gm...> - 2005-10-14 08:34:48
|
Alex, 2005/10/14, Alex Roitman <sh...@gr...>: > > No, what I meant was the upgrade function that will run > automatically on opening the database if the > database version is lower than what will ship with 2.0.9. > We have already done 6 or 7 of those, so it's nothing new. Ah, great. > > Is this always a safe thing to do? I did it a couple of weeks ago and > > it worked, I think. The only strange thing was the given name-based > > sex-guessing, it started from scratch after the reload. > > We thought it was, but today I found out that "estimated" and > "calculated" were missing from XML import/export. This will > be fixed in 2.0.9 (already fixed in CVS). Ugh, I did not notice. I did not have many of those, I'll check my CVS to see if I lost anything important. By the way, with respect to sex-guessing, I just sent in a change to default the sex for new parents to unknown. This way sex guessing works and if not guessed or set you will get a warning. It had become a routine for me to fix a mother inadvertently added as a male (the previous default). I think the behaviour is now saner. Regards, Julio |