DISCUSS: TaskStatusDB: Switch to storing status name instead of value?

[dwhswenson]

In original development, I stored the integer value associated from the TaskStatus enum for a given status. The question here is whether to instead use string name from the enum. At this point I don't have a strong preference of one over the other, although I'm leaning a bit toward using the string name. Here are the advantages I see to each choice:

Why to use string name:

• Allows us to use sqla.Enum as column type, which may do better validation of values (haven't checked this, but we're certainly not currently preventing the DB from storing an int with no meaning from the enum)
• More obvious output if user directly works with DB (e.g., loading tasks table with a pandas data frame): meaningful string instead of meaningless int
• (I think) it will allow us to immediately get the enum object back, instead of converting the int value into the enum object being our responsibility. This could simplify future code based on an existing task database (dashboards, consistency checks, etc.)

Why to use int value:

• Possible performance improvements (space and speed) over storing CHAR/VARCHAR.
• If sqla.Enum is internally using CHAR, there might be migration issues if a new status is added to the enum (different CHAR length might be required)
• In the short term, I think we're more likely to change the name of a status than its numerical value. That would be breaking for existing DBs using different string names.