From: Benny M. <ben...@gm...> - 2008-04-07 10:56:27
|
2008/4/5, Douglas S. Blank <db...@cs...>: > > Ok, I think I have a viable database change plan with minimal impact, and > only a slight increase in record size. There are two items I am looking > at: 1) adding an interpreted date setting (INT from gedcom, see: > http://bugs.gramps-project.org/view.php?id=1210) and 2) adding a newyear > code (see: http://bugs.gramps-project.org/view.php?id=1133) > > I propose adding the INT to the quality property of the date class, but > making all of the qualities be bitwise so that you can mix and match, > like: > > QUAL_NONE = 0 # BITWISE > QUAL_ESTIMATED = 1 > QUAL_CALCULATED = 2 > QUAL_INTERPRETED = 4 > > This doesn't increase the size of a date object, and makes the dates more > flexible (so that you could have a EST CAL INT date, if you wished to). Have a good thing how to store this in XML. At the moment we use 'estimated' or 'calculated' string. This can give quite some upgrade and interprestation issues. XML should also remain somewhat readable, having type being CDATA is not as nice as a list of possibilities, as CDATA is quite general. The second change is to add a integer to date which will represent the > month/day on which the year of a date begins. As suggested by RootsNerd, > we will start with these 4 common cases: > > NEWYEAR_JAN1 = 0 # CODE > NEWYEAR_MAR1 = 1 > NEWYEAR_MAR25 = 2 > NEWYEAR_SEP1 = 3 > > and add more as needed. Ok, you do the work, so I will not oppose. A note though, this is very much linked to a calendar, so it would be best if these are interpreted with respect to the calendar, no? So if Hebrew calendar, then this field has no meaning. It would be nice if this could be reflected in the data storage and the names of the variables. So perhaps NEWYEAR_GRE_JAN01. Again, don't forget the XML format http://www.gramps-project.org/xml/1.2.0/everywhere where cformat is used, a field must be added. You can discuss with Alex how best to do this. The date structure is much repeated Afterwards comes the harder part: figuring out the UI and parser (as noted > by Benny). If no one has any objections or sees any problems with these > changes, I'll go ahead and commit. > > -Doug > > |
From: dsblank <db...@cs...> - 2008-04-08 04:31:51
|
I've committed the changes to upgrade all dates to contain a newyear code when updating to db v. 14. Benny Malengier wrote: > > Have a good thing how to store this in XML. At the moment we use > 'estimated' > or 'calculated' string. This can give quite some upgrade and > interprestation > issues. XML should also remain somewhat readable, having type being CDATA > is > not as nice as a list of possibilities, as CDATA is quite general. > Good point. I'll take a look at the XML next. >> The second change is to add a integer to date which will represent the >> month/day on which the year of a date begins. As suggested by RootsNerd, >> we will start with these 4 common cases: >> >> NEWYEAR_JAN1 = 0 # CODE >> NEWYEAR_MAR1 = 1 >> NEWYEAR_MAR25 = 2 >> NEWYEAR_SEP1 = 3 >> >> and add more as needed. > > > Ok, you do the work, so I will not oppose. > A note though, this is very much linked to a calendar, so it would be best > if these are interpreted with respect to the calendar, no? So if Hebrew > calendar, then this field has no meaning. It would be nice if this could > be > reflected in the data storage and the names of the variables. So perhaps > NEWYEAR_GRE_JAN01. > It will be slightly more general than a single calendar (can be used with at least Gregorian and Julian) but point taken. Thanks! -Doug > Again, don't forget the XML format > http://www.gramps-project.org/xml/1.2.0/everywhere where cformat is > used, a field must be added. You can discuss > with Alex how best to do this. The date structure is much repeated > >> Afterwards comes the harder part: figuring out the UI and parser (as >> noted >> by Benny). If no one has any objections or sees any problems with these >> changes, I'll go ahead and commit. >> >> -Doug > -- View this message in context: http://www.nabble.com/Year-change%2C-Was%3A-How-does-one-change-the-db--tp16538387p16547530.html Sent from the GRAMPS - Dev mailing list archive at Nabble.com. |