Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Null string values - decision needed #1183

Open
kpodp0ra opened this issue Dec 21, 2024 · 1 comment
Open

Null string values - decision needed #1183

kpodp0ra opened this issue Dec 21, 2024 · 1 comment

Comments

@kpodp0ra
Copy link
Contributor

Here is what I discovered

  1. Backend allows you to put empty strings as a text value
  2. Frontend changes them to null before sending API request
  3. Null values and empty strings are looking the same in UI
  4. There is a bug in aggregation:
    const flagString = `${currentGroupFieldId}_${groupByValueString}`;
    const groupId = String(string2Hash(flagString));

    Aggregation gives the empty string and the null string the same hash (see screenshot above where count is 4, not 2)
  5. isEmpty and isNotEmpty checks only for null values
    Resolution: fix: better match empty text fields #1181

Here is what ChatGPT thinks:

It's crucial to allow users to distinguish between empty strings and NULL values in databases because they represent different states with real-life implications. Here are key use cases where this distinction matters:

  • Contact Information: Empty strings mean the user explicitly chose not to provide data, while NULL signifies the data hasn't been addressed yet.
  • Survey Responses: Empty strings indicate a deliberate choice to leave a question blank, while NULL reflects that the question wasn't shown or interacted with.
  • E-Commerce: Sellers can indicate no product description is needed (empty string), while NULL flags pending updates.
  • Application Settings: Empty strings express "no preference," whereas NULL highlights unset configurations.
  • Medical Records: Empty strings confirm no allergies, while NULL signifies unknown allergy status.

My opinion

I know that implementing such a distinction may require some planning and work, but for me, it would be really useful if the null values would be shown as a dark dot or something like DataGrip has. This would allow me to distinct which values are empty on purpose and which are not yet filled.

Remember that you can hide fields in views, and these fields stay hidden in creation-modal. If one people in the company create records and others edit them, it is good to distinguish which fields have been populated.

Also, we have NULL and 0 values in number fields, why we don't implement this mechanic in strings?

I need feedback and decision what path we should go

If we want to keep null values and empty fields unambiguous, I would consider unifying the backend and frontend by changing the empty field to null on the server side.

But if we want to keep null values and empty fields separate, as LLM suggests, we should discuss if we want to and how to distinguish them visually in UI. JetBrains DataGrip does it like this:

We would also need some context-action to set NULL values:

Also, we would need NULL-button here:

And then there is the side issue of how we do with grouping. Should the null and empty string be treated by the aggregation as the same, or should we keep them in separate groups (as it is currently).

@tea-artist
Copy link
Contributor

tea-artist commented Dec 22, 2024

I currently prefer not to save empty strings at the Teable application and API level, and to convert all empty strings to null before saving, In Excel, empty strings are also treated as null, which seems to be more intuitive for non-tech people. (by the way display <null> will also confuse non-tech people

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants