number 5 will be imported as a string “NULL” but number 3 will be imported as a NULL value. of course, this is why you sanitize the data (GIGO) but I can imagine this happening countless times at companies all over the country
fetch('/api/user/1')
.then(response => response.json())
.then(data => {
if (data.lastName == "null") {
console.log("No last name found");
} else {
console.log("Last name is:", data.lastName);
}
});
if data is
data = {
id: 5,
lastName: "null"
};
then the if statement will trigger- as if there was no last name. that’s why you gotta know the language you’re using and the potential pitfalls
now you may ask – why not just do
if (data.lastName === null)
instead? But what if the system you’re working on uses JSON.parse(data) and that auto-converts everything to a string? it’s a very natural move to check for the string "null"
obviously if you’re paying attention and understand the pitfalls of certain languages (like javascript’s type coercion and the particularities of JSON.parse()) it becomes easy but it’s something that is honestly very easy to overlook
Like you said, GIGO, but I can’t say I’m familiar with any csv looking like that. Maybe I’m living a lucky life, but true null would generally be an empty string, which of course would still be less than ideal. From a general csv perspective, NULL without quotes is still a string.
If “NULL” string, then lord help us, but I would be inclined to handle it as defined unless instructed otherwise. I guess it’s up to the dev to point it out and not everyone cares enough to do so. My point is these things should be caught early.
I’ll admit I’m much more versed in mysql than postgres.
It’s baffling to me. Maybe I’m just used to using “modern” frameworks, but the only way this could be an issue is if you literally check if the string value equals “null” and then replace it with a null value.
NULL!= ‘NULL’How do devs make this mistake
Code is easy in a vacuum. 50 moving parts all with their own quirks and insufficient testing is how you get stuff like this to happen.
it can happen many different ways if you’re not explicitly watching out for these types of things
example let’s say you have a csv file with a bunch of names
id, last_name 1, schaffer 2, thornton 3, NULL 4, smith 5, "NULL"if you use the following to import into postgres
COPY user_data (id, last_name) FROM '/path/to/data.csv' WITH (FORMAT csv, HEADER true);number 5 will be imported as a string “NULL” but number 3 will be imported as a NULL value. of course, this is why you sanitize the data (GIGO) but I can imagine this happening countless times at companies all over the country
there are easy fixes if you’re paying attention
COPY user_data (id, last_name) FROM '/path/to/data.csv' WITH (FORMAT csv, HEADER true, NULL '');sets the empty string to NULL value.
example with js
fetch('/api/user/1') .then(response => response.json()) .then(data => { if (data.lastName == "null") { console.log("No last name found"); } else { console.log("Last name is:", data.lastName); } });if
dataisdata = { id: 5, lastName: "null" };then the if statement will trigger- as if there was no last name. that’s why you gotta know the language you’re using and the potential pitfalls
now you may ask – why not just do
if (data.lastName === null)instead? But what if the system you’re working on uses
JSON.parse(data)and that auto-converts everything to a string? it’s a very natural move to check for the string"null"obviously if you’re paying attention and understand the pitfalls of certain languages (like javascript’s type coercion and the particularities of
JSON.parse()) it becomes easy but it’s something that is honestly very easy to overlookLike you said, GIGO, but I can’t say I’m familiar with any csv looking like that. Maybe I’m living a lucky life, but true null would generally be an empty string, which of course would still be less than ideal. From a general csv perspective, NULL without quotes is still a string.
If “NULL” string, then lord help us, but I would be inclined to handle it as defined unless instructed otherwise. I guess it’s up to the dev to point it out and not everyone cares enough to do so. My point is these things should be caught early.
I’ll admit I’m much more versed in mysql than postgres.
“True”
It’s baffling to me. Maybe I’m just used to using “modern” frameworks, but the only way this could be an issue is if you literally check if the string value equals “null” and then replace it with a null value.
lastName = lastName.ToUpper() == "NULL" ? null : lastName;Either that or the database has some bug where it’s converting a string value of “null” into a
null.That is something I’ve had to do on rare occasions because people set up and store info in stupid ways…
How do devs make off by one mistakes.
The most common source of security vulnerabilities is memory corruption and off by one errors.
(to make the joke more obvious)
The two most common sources of security vulnerabilities are buffer overflows, use-after-free, and off-by-one errors.