OK, in r10405 I've gotten all the get-ready work done for bug #1680,
which will get rid of the deprecated CAUSE_DEATH (Cause Of Death) event
type from eventtype.py. This will use a new "blacklist" functionality in
GrampsType which hides obsolete/retired type values without actually
removing the old data.
I have not yet removed CAUSE_DEATH because that would break databases
that have existing events of that type.
==> So I am looking for suggestions on how to proceed from here.
Here's the first scenario that comes to mind (but see [note0]):
1) On reading a database, convert CAUSE_DEATH events (with description)
to new DEATH events[note1], putting the description into the attribute
CAUSE ("Cause"). Log output and UI feedback should be generated and it
would be nice to show a list of individuals affected, maybe.
2) On importing[note2] from various formats (I guess that means: xml,
grdb, gedcom), it should do the exact same stuff as step (1), no?
3) Import and export modules (including eg, _GedcomParse.py and
_WriteGedcom.py) and maybe some db handling code can remove leftover
unreachable code not needed for step (2).
4) Don't forget [note0].
- - -
[note0] Looking forward to a time when there are many obsolete/retired
types, it seems like it may NOT be a good idea to carry such conversion
code along forever. Maybe just one point-version's worth, or _some_
version-based cutoff. Or maybe it shouldn't be part of mainline code at
all? Perhaps opening a database or importing a file should simply report
blacklisted types and tell the user to find and run a specific
standalone conversion utility. There might be a sequence of these:
fix3.1 fix3.2, fix4.0 (4.0 also rolls-up all the 3.x since 3.0?).
Even with only a few obsolete type values to blacklist, I can imagine
that the fixup code would tend to clutter mainline code and constrain
the freedom of future design changes.
[note1] Multiple DEATH events is not forbidden. A utility operation to
find/display such multiples might be a useful diagnosis/repair tool. In
fact, generalizing this utility might produce a nice convenience tool.
There is no reason to prohibit multiples, but it might still be nice for
the user to be able to have a look on demand.
[note2] Exporting should not have to do any of this fixup/conversion,
since the database will have been already purged of the obsolete type
values. But see step (3).
- - -
It seems I have argued myself into preferring a freestanding tool to do
such migration chores. Are there some examples of that kind of code for
me to look at?
Who's got some past-practice information and/or ideas?
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
Gramps-devel mailing list