-
-
Notifications
You must be signed in to change notification settings - Fork 634
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
Comments
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 |
I see both sides, as in I also don't like saving an empty value, and instead maybe prefer putting a checkbox (a boolean) setting if the question got answered. On the other hand, having some data manipulation that might be unwanted and not immediately exposed to the user/developer is also weird. What I suggest is maybe adding an option in the field like |
@alexfacciorusso I think this is a good idea. But, I think the default state should be enabled for Similarly, if this option is turned off, display a @kpodp0ra What do you think? |
For the grouping situation, distinguishing between null and empty strings should be in line with expectations because we can already use |
Here is what I discovered
null
before sending API requestteable/apps/nestjs-backend/src/features/aggregation/aggregation.service.ts
Lines 199 to 200 in 8b3df68
Aggregation gives the empty string and the
null
string the same hash (see screenshot above where count is 4, not 2)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:NULL
signifies the data hasn't been addressed yet.NULL
reflects that the question wasn't shown or interacted with.NULL
flags pending updates.NULL
highlights unset configurations.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).
The text was updated successfully, but these errors were encountered: