Feature flag for string-valued columns: preferred way to represent "no data"

[p.colbert]

Specifies how to store and retrieve a value that indicates “no data”.

In my Oracle databases, NULL and the empty string were the same value, saving a ton of headaches. A visual “null” (no characters) and a database NULL were the same thing, so the GUI and database agreed, and queries held fewer surprises.

In Anvil, a string-valued column can store “no data” in two different ways: as an empty string (e.g., if it came from a TextBox or TextArea) or as a None (the default value).

Having two different values mean the same thing to you, but not to Python, nor to search(), can greatly complicate your related code.

In those cases, such a flag would help, by making it easy for you to standardize on just one. For a string-valued column that appears in user interfaces, you might set its standard to be an empty string, for consistency. For one that’s used solely behind the scenes, you might set its standard to None.

The default value for such a flag would be the status quo: None and the empty string are distinct values, in the database, and search() would treat them as different. So unless someone went out of their way to set that column’s flag differently, Anvil’s existing behaviors would be preserved.

Edit: Current workaround: see the strategy described here:

"Dataless" strings vs. None/NULL -- a possible strategy

What I’m trying to do: Reconcile GUI and DB standards, with regard to empty strings. In a TextBox or TextArea, an empty string and a None are visually indistinguishable – and to avoid confusing users, they probably should be. Strategically, GUI code should probably standardize on "" as the “no data” value for such fields, as then the type will always be str, which will always work with the str-related functions and operators. If these are applied to a None value, they will error out (raise a…

Edit 2: Given the replies to the above, this may be broader than strings. CheckBoxes present a similar situation: None and False look alike on-screen (and usually should), but not in the database.