Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We have an employee whose last name is Null. He kills our employee lookup (2012)

stackoverflow.com

Post reply on HN
Print view View original

241–245 of 245 posts

Re: We have an employee whose last name is Null. He kills our employee lookup (2012)

#241

Post by ams6110 »

rmc wrote: post #204
lostlogin wrote: post #130

Earlier quoted context omitted.

I've never understood why people entering data into a system enter an initial. It's a partial entry. You wouldn't enter a date of birth as 3. On further thought, actually, they do. Then dismiss all the error messages and quit the program to get past the system keeping them in the field waiting for completion. Users seem hell bent on breaking our databases.

Some people have surnames that are only one letter.

Particularly names in southern regions of India, where traditionally people would have only a single name (no surname) and when a surname is required they might give the first letter of their father's name.

Re: We have an employee whose last name is Null. He kills our employee lookup (2012)

#242

Post by Piskvorrr »

Mvandenbergh wrote: post #224
Piskvorrr wrote: post #217

Earlier quoted context omitted.

Well, you can still get bitten by "11. People’s names are all mapped in Unicode code points," as well as the sets 1-8 and 32-36 (people have exactly X names at a given point in time, where X>0); that's not to mention ordering and collation (12,13,18,30). But it's definitely the easiest option, and avoids many common pitfalls (if I had a nickel for every database using latin1 + latin1_swedish_ci because that's the fir…

I can see 11, but as long as you're not using the name as a unique key but just as a label then the mutability, non singularity, and non-orderedness aren't such problems.

That makes sense - I was under the impression that you need to keep the name's history etc; even so it wouldn't be much of a problem.

Re: We have an employee whose last name is Null. He kills our employee lookup (2012)

#243

Post by mcv »

Steko wrote: post #171
dublinben wrote: post #165

Earlier quoted context omitted.

When your father dies, and you've named your son Norman John Harman as well, don't you become senior? It's can't be an immutable part of your name if your junior/senior status changes.

He'd become NJH II.

To me, Americans with III after their name always look like they're pretending to be royalty. Where I live, only monarchs have that (and only after their first name).

Re: We have an employee whose last name is Null. He kills our employee lookup (2012)

#244

Post by afandian »

seanmcdirmid wrote: post #182
SiVal wrote: post #173

Earlier quoted context omitted.

Yes, and imagine the impact this has on "foreigners who work in China" such as Tibetans in Lhasa.

Tibetans (with Hukou anyways) have Chinese names though. Usually they are phonetically chosen. Its something that must be done when you are born in China I guess, even if your native language isn't Chinese. This applies to all minorities who use different writing systems (Uigher, Manchu, Mongolian, etc...). Japanese of Korean descent can also choose Kanji names I think, to use as legal aliases.

I think SiVal was making making a reference to China's invasion of Tibet.

Re: We have an employee whose last name is Null. He kills our employee lookup (2012)

#245

Post by neilk »

jameshart wrote: post #222
neilk wrote: post #176

Earlier quoted context omitted.

Perhaps I was unclear, but I did not claim that there could be one single sanitized version of the data, safe for all use cases. I was saying that you have to do different sanitization for every output.

That's not called 'sanitizing', it's called 'escaping' and 'encoding'. The byte sequence I need to store to communicate the name "Kei$ha O'Shaughnessey, Jr." in a UTF-8 JSON string literal, a UTF-8 HTML attribute, a UTF-16 bigendian CSV file, or an ISO-8859 SQL parameter, are going to be different - but so long as all the characters I need to pass are representable in all of those domains all I have to do is perform…

A strategy of 'escaping' assumes that the partner system does the right thing with its data. This is not always the case.

For instance, it may be perfectly fine in my system to have a user named 'alert("ha!")'. Are you sure that's okay in your PHP-based web forum? Really sure? Every place they've ever shown a username to the user, it's well-escaped?

And even if that's true today, what about the day when someone decides to change the web forum software to something else? What about the day when someone turns on a feature that copies certain forum threads to an internal support system, also provided by a third party?

Post reply on HN