The hazards of really large numbers
The new version of Blogger uses 18-digit numbers for post ID numbers, rather than the old 8-digit numbers. Until just now, I thought that was just a handy way to tell new.blogger blogs from old, and an amusing statement on just how big Blogger plans to grow, rather like small companies that use account numbers large enough to cover twice the population of the world (and then inevitably require you to write your account number on your check). Now, I’m not quite so amused, thanks to a question about my remote dotcomments hack.
Though it really should be updated to a more modern and accessible link style, dotcomments and remotedotcomments both link to a comment popup by calling a javascript function with javascript:viewComments(<$BlogItemNumber$>), and then the function sticks the item number into a URL and opens it. Unfortunately, javascript being dynamically typed, and there being no quotes around <$BlogItemNumber$> to force it to be a string, that’s an actual number up until it gets concatenated to a string in the URL, when it gets cast to a string. Oopsie, 18 digits is exactly one more than the precision of a javascript number, so your item ID of 123456789012345678 turns into 1.2345678901234568 times 10 to the whatever, with the 78 rounded up to 80, so the number that dotcomments uses for comments on an entry isn’t actually the number of the entry. The fix is simple enough, add quotes around the number so it’s a string: javascript:viewComments('<$BlogItemNumber$>'), but now I’m trying to quickly think of every bit of javascript I’ve ever written and released that might treat post numbers as anything but strings, because according to the unlinkable, unarchived, newest post on the Blogger home page, the changeover for everyone is a-comin’ soon.
Make that, a problem for javascript and for PHP.
Uh-oh. Thanks for pointing this out…
Yeah, once I realized that my non-remote dotcomments was failing to count, because 18 digits is too much for PHP, being more than double-precision for anything, I realized that lots of folks are going to be screwed, in places they probably didn’t expect.
Now, if Blogger were really good at anti-competitive behavior, they would have their own comment system ready to roll out right now: click a button, fill in your credit card number, get working comments added automatically.
I’m not even sure how to fix this. Even with treating the numbers as strings in JavaScript and PHP, the JS count is gonna fail because it’s looking for the content of array cell [id#]… unless JS can handle named array cells. (??)
I’ve expected Blogger to roll out a commenting system for so long now, I don’t know what to expect. I mean, they have one on their Brazilian site at the moment. (Can’t remember how it works exactly, but if it’s affected.) To be fair, though, it would be in their best interests to add a built-in system.
Javascript can handle named array cells – you can use a string as an array index, just like in PHP. I think this was introduced in Javascript 1.2 but that’s supported in every browser since Netscape 4 as far as I know.
An additional problem with this is that if you are sending by email a permalink of a long (more that 72 chars) URL, maybe because your domain name is also long, some email programs wrap the long line in two… and the link no longer works.
I assume this is going to be the case for aspcomments as well, since it uses the same ”
javascript:viewComments(” as a link. Thanks for pointing this out!
Certainly the case for the link; next question is whether it’s also the case internally anywhere. I can’t find the post-it with my password for my Brinkster free ASP account, so I haven’t tested it, but you might want to create a Dano test blog, and see whether anything in the script itself breaks from treating the post ID as a number once it gets passed in. I assume from what Marcus said here and his ”wine doesn’t help panic coding” post that BlogBack does a fair bit of treating the post ID as a number internally, and I wouldn’t be a bit surprised if lots of other systems do, too, because it seemed so reasonable right up until this minute.
Actually its not as easy as that as aspcomments won’t accept those large numbers in the database (it’s only using a double integer for the database). if you convert the database to integer and then use a decimal place of 20 then you get the aforementioned error. So just putting a string round it won’t work, unless you change the database to look for strings instead of numbers…. Thats not something i’m willing to try on my live data!
I wonder of it would be easier to just go to 17 digits. :D Or maybe 16 hexadecimal ones, or something like that.
I’m more than a little curious about how they happened to choose 18 digits, and how they deal with it. Does Java have slightly higher precision than the rest of us?
If you look closely, you’ll see that that huge number is just a the number of seconds since epoch with some random digits (possibly more precision?) added to the end. It’s a huge annoyance for me since I use 32-bit integers instead of strings to index comments. However, I think I’m the only person actually doing this :)
Blogger.com.br used the 18-digit numbering for a long time, but they recently switched back to the old style of sequential post IDs which start from 1. I wonder why they changed it?
oops, I meant to type ”just the number of seconds”…
Urr. I might have noticed that, except I always hide the actual number of seconds from myself with code, so it’s not even a vaguely familiar number to me. What you probably are is the only person using a strongly-typed language for comments, so at least you knew whether you were using strings or numbers: I hadn’t ever really noticed that dotcomments starts out with a number, goes to a string, maybe back to a number, sideways to a string of only digits…
I must admit, this is something I didn’t know. Thanks for sharing this issue. Now I’ll keep that in mind when I encounter some gargantuan number in PHP.
I managed to fix the asp comments thing and post the (simple) instructions online at absoblogginlutely
Thanks for pointing this out. If not for you, I would have eventually had to find out the hard way.
Glad you spotted it. I meant to run through all the scripts I know of, seeing whether they are fixed (I got as far as PosterChild, and saw that he fixed it a couple weeks before I knew about the problem), but I got distracted.
The hard way is coming up fast, though. From what I hear, the forced migration apparently started either yesterday or today.