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

Congratulations on creating the one billionth repository on GitHub

github.com

Post reply on HN
Print view View original

81–90 of 146 posts

Re: Congratulations on creating the one billionth repository on GitHub

#81

Post by lmm »

lcnPylGDnU4H9OF wrote: post #68
jiggawatts wrote: post #64

Earlier quoted context omitted.

Not the original commenter, but I've read through half a dozen post-mortems about this kind of thing. The answer is: yes. There's challenges and sometimes downtime and/or breaking changes are inevitable. For one, if your IDs are approaching the 2^31 signed integer limit, then by definition, you have nearly two billion rows , which is a very big DB table! There are only a handful of systems that can handle any kind of…

> For one, if your IDs are approaching the 2^31 signed integer limit, then by definition, you have nearly two billion rows Just wanted to nitpick this; this is not actually definitively true. A failed insert in some systems will increment the counter and deleting rows usually does not allow the deleted ID to be re-used (new inserts use the current counter). Of course, that is beside the point: the typical case of a t…

It's actually fairly common to see this problem crop up in systems that are using a database table as a queue (which is a bad idea for many reasons, but people still do it) in which case the number of live rows in the table can be fairly small.

Re: Congratulations on creating the one billionth repository on GitHub

#82

Post by NooneAtAll3 »

cheschire wrote: post #26
School-Cotton wrote: post #13

On a serious note, I'm a bit surprised that GitHub makes it trivial to compute the rate at which new repositories are created. Isn't that kind of information usually a corporate secret?

When your moat is a billion wide, you tend to walk around in your underwear a bit more I guess.

unless you're youtube?

Re: Congratulations on creating the one billionth repository on GitHub

#84

Post by 90s_dev »

extraduder_ire wrote: post #83
90s_dev wrote: post #36

This is either staged, or incredible commentary on most github repos , having no purpose, never being realized, and even having given up dreaming .

I think, by design, every commit in git is staged.

Wow.

Re: Congratulations on creating the one billionth repository on GitHub

#85

Post by topherPedersen »

CGamesPlay wrote: post #71

Probably created via a script that just repeatedly checked https://api.github.com/repositories/999999999 until it showed up, and then created a new repository. Since repositories can be modified, could have even given it some buffer and created a bunch of repos, just delete the ones that don't get the right number. [append] Looking at the author's other repo created yesterday, I'm betting "yep" was supposed to be the…

You solved the mystery!

Re: Congratulations on creating the one billionth repository on GitHub

#86

Post by azophy_2 »

rudasn wrote: post #56
hobs wrote: post #53

Earlier quoted context omitted.

heh, that's happened at at least 5 companies I have worked at - go to check the database, find - currency as floats, hilarious indexes, integers gonna overflow, gigantic types with nothing in them.

I bet you haven't seen indeces on decimals though! Fun times :)

Just curious as someone with limited experience on this. Whats wrong with it? decimal is consistent & predictable (compared than float), so it shouldn't be that big of a deal right? CMIIW

Re: Congratulations on creating the one billionth repository on GitHub

#87

Post by hu3 »

handfuloflight wrote: post #32
recursive wrote: post #30

Earlier quoted context omitted.

I don't believe they will renumber the old ones. Also, it can't be trivial, since two people can try this, and only one can win.

There is always one trillion to look forward to!

bogus aí agents stuck in loops will get us there soon enough

Re: Congratulations on creating the one billionth repository on GitHub

#88

Post by dietr1ch »

xboxnolifes wrote: post #43
raincole wrote: post #25

Earlier quoted context omitted.

Is there any reason for GitHub to hide this information though? How could it be used against them? (I understand many companies default to not expose any information unless forced otherwise.)

Companies usually hide this type of information so competitors have a harder time determining if they are growing/shrinking/neutral.

And engineers thinking of scale would usually try to steer away from a sequential id because of self inflicted global locking and hot spots.

Re: Congratulations on creating the one billionth repository on GitHub

#89

Post by tengbretson »

gchamonlive wrote: post #62
bartread wrote: post #50

Earlier quoted context omitted.

The company where I did my stint as CTO I turned up, noticed they were using 32-bit integers as primary keys on one of their key tables that already had 1.3 billion rows and, at the rate they were adding them, would overflow on primary key values within months… so we ran a fairly urgent project to upgrade the IDs to 64-bit to avoid the total meltdown that would have ensued otherwise.

What are the challenges of such projects? How many people are usually involved? Does it incur downtimes or significant technical challenges for either the infrastructure or the codebase?

If you've written your services in JavaScript, going from i32 to i64 means your driver is probably going return it as a string (or a BigInt or some custom Decimal type), rather than the IEEE754 number you were getting before. This means you now need change your interfaces (both internal and public-facing) to a string or some other safely serializable representation. And if you are going to go through all that trouble, you may as well take the opportunity to just switch to some uuid strategy anyway.

The alternative is that you can monkey-patch the database driver to parse the i64 id as an IEEE754 number anyway and deal with this problem later when you overflow the JavaScript max safe integer size (2^53), except when that happens it will manifest in some really wacky ways, rather than the db just refusing to insert a new row.

Re: Congratulations on creating the one billionth repository on GitHub

#90

Post by jamwil »

lmm wrote: post #81
lcnPylGDnU4H9OF wrote: post #68

Earlier quoted context omitted.

> For one, if your IDs are approaching the 2^31 signed integer limit, then by definition, you have nearly two billion rows Just wanted to nitpick this; this is not actually definitively true. A failed insert in some systems will increment the counter and deleting rows usually does not allow the deleted ID to be re-used (new inserts use the current counter). Of course, that is beside the point: the typical case of a t…

It's actually fairly common to see this problem crop up in systems that are using a database table as a queue (which is a bad idea for many reasons, but people still do it) in which case the number of live rows in the table can be fairly small.

If a SQLServer instance is killed unceremoniously it adds 1000 to the pk increment.
Post reply on HN