Comment by robbiet480
9 years ago
Just hit this problem again this morning. Quite annoying. I figured out what string was empty eventually, but i've solved this on other projects by just removing all keys with empty values to get around possible errors.
The problem we have is that we're trying to store JSON provided by the user. Meaning that we need to persist empty strings provided by them. The only way I can see around this issue is to replace all empty strings with a special string token on the way in, and replace all those special string tokens on the way out.
See that's the best use case I've seen in this entire discussion. If you don't get to control if blank vs null is significant then I can see how you'd have a real issue on your hand.
I'm guessing you have to have it in a form you can search it (so you can't just GZIP it or something like that)?
This is all correct.
Append all strings with a zero width space, and remove it on the way out.
Using a printable character (or sequence of characters) seems like it would be a lot better. It'll ugly up your database, but at least it'll be obvious that there's a difference. Having all your string possess two forms which are visually identical but are not actually the same sounds unpleasant.
I think it would be better to use something both printable and commonly used for placeholders, eg. an underscore, so it's obvious if you forget to remove it and unlikely to seriously confuse anybody.
What if the user has a string ending with a meaningful zero width space already stored? For example, the string could be checksummed somewhere. It would corrupt their data.
If you want a kludge for this, it's better to generate a longish random string (e.g., a UUID) to indicate an empty value.
4 replies →
Is the zero width space destined to be the next maligned value, comparable to null?
It's too bad DynamoDB can't just do this conversion for me.
3 replies →