Frankly, it's been a while since I worked on Dynamo so I can't say for sure. I don't see a fundamental reason not to support null and zero-length. On the other hand it seems more like a convenience than a necessity, since you can encode those.
You may have different use-cases in mind, but it seems that if you're writing nulls you're using the key-value store to distinguish between keys that do or don't exist - basically storing a large set rather than a large map. And in that case you can write a small value to encode null and you won't change the value (rather you will delete the key-value entry).
I think this takes us to an API design discussion - I don't feel strongly about it. But I'd love to hear if that caused you significant burden or trouble in your application.
To be clear, I'm talking about nulls and zero-length strings/bytearrays as values, not as keys. I suppose it does boil down to API design though, yeah.
I guess I'm saying: Querying for something and getting null, "", or bytes("") has a different meaning and - crucially - a different type than undefined or DNE. Supporting these just seems like such a straightforward win in terms of language interop and usability that I was curious what the constraints and such were that caused the current state of affairs. If it's been a while, I certainly understand. Just something that I've wondered for a bit.
You may have different use-cases in mind, but it seems that if you're writing nulls you're using the key-value store to distinguish between keys that do or don't exist - basically storing a large set rather than a large map. And in that case you can write a small value to encode null and you won't change the value (rather you will delete the key-value entry).
I think this takes us to an API design discussion - I don't feel strongly about it. But I'd love to hear if that caused you significant burden or trouble in your application.