Difficult stuff.

2008/3/27, James G. Sack (jim) <jgsack@san.rr.com>:
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.

Good idea. Try to make it general, so we can use the mechanism more generally, like separate family events from person events, ...

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.

We could also convert to a CUSTOM TYPE, so keep the data of the user, but now as custom type instead of predefined type.
Automatic conversions are not really liked by advanced users, be it as custom type or to death event.
We could add options, but it is annoying to bother users on import with an option 'Change CAUSE_DEATH event to:' if he does not have that info in the file.

As another option, do we need to remove this type from GRAMPS? We could blacklist it and not show it anymore (I think NoteType does things like that), but just keep it around.
Then only GEDCOM export must be changed and handle old CAUSE_DEATH events as custom event or as attribute to DEATH...

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?

Yes. For import of xml I added an info object, and a messagedialog after import with the info text.
The idea is to move to a gtk.Assistant in the future, and use the info text on the final assistant page.

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).

Yes. If we just leave CAUSE_DEATH but blacklist it, only gedcom export must change, and the rest remains the same. We could then provide a tool: convert events (it exists already), and let users run this tool to change database/xml info. We could adapt the tool to have a specific CAUSE_DEATH change option that would add the CAUS attribute to the death event if that is present.

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.

Every database change means tools and upgrade paths. It is important to not only fix issues in GRAMPS, but also offer the required tools to the user. Eg, the check and repair tool could have code to remove the CAUS_DEATH event and replace it. Question is, does the user want to have that done automatically, or should it be another tool, or part of the change eventtype tool?

[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