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

Things you should do now (2011)

secure.phabricator.com

Post reply on HN
Print view View original

101–110 of 115 posts

Re: Things you should do now (2011)

#101

Post by T-hawk »

bob1029 wrote: post #99
closeparen wrote: post #98

Earlier quoted context omitted.

One concurrent insertion, or one network partition. UUIDs can be generated on many machines with no awareness of each other and merged later.

I would recommend reviewing my prior comments on this, as I address the concerns of multiple nodes needing to be able to independently produce identities without collisions or coordination. If you know beforehand the maximum number of participants in your system, you can divide the keyspace across that quantity. If you are using BigInteger or equivalent, you have an infinite number of these things to work with, so it…

If you're going to use a key space in the trillions, and partitioned and sparsely populated rather than sequential... isn't that just reinventing what the UUID already is?

A UUID is just a 128-bit integer, with creation algorithms designed to partition that space by things that already have enough entropy to need no further synchronization.

What you're proposing sounds like roll-your-own-UUID, which might be similarly inadvisable as roll-your-own-crypto.

Re: Things you should do now (2011)

#102

Post by treis »

boris wrote: post #33

For me #1 would be to add a version to any data format or communication protocol. If you want to know how hard not doing so can bite, don't look further than Git and it's tourcherous migration from sha1.

I've started to lean more and more against versioning as time has gone on. The problem is that it's an invitation for users to stay on a specific version indefinitely. Which makes your life much harder as you have to ensure all of these old versions continue to work while backporting critical fixes. I prefer a continuous deprecation cycle where you support things in parallel for a while, then add deprecation warnings, and finally remove the functionality. How fast this happens depends on how critical the issue is.

Versions make sense in a lot of areas where stability is needed. But they should be seen as issuing binding contracts to your users. You should spend a lot of time thinking about what the terms and conditions are before doing so.

Re: Things you should do now (2011)

#103

Post by neves »

nostrademons wrote: post #83
marcus_holmes wrote: post #20

Things you should never do: use integers as ID's. This is literally a solved problem, and the solution is UUIDs, which were invented for exactly this job.

One of the best pieces of programming advice I got at Google was consider IDs carefully . This is not a solved problem, and there isn't a one-sized-fits-all solution. Rather, there are a bunch of guide rules, and then you need to understand your problem domain very well to choose good identifiers. An ID should be: 1.) Actually an identifier , i.e. it needs to identify objects uniquely and must be immutable throughout…

Great answer. Don't forget the user experience of the developer. You must always copy'n paste GUIDs, but you can type integers.

Re: Things you should do now (2011)

#104

Post by andrewflnr »

T-hawk wrote: post #101
bob1029 wrote: post #99

Earlier quoted context omitted.

I would recommend reviewing my prior comments on this, as I address the concerns of multiple nodes needing to be able to independently produce identities without collisions or coordination. If you know beforehand the maximum number of participants in your system, you can divide the keyspace across that quantity. If you are using BigInteger or equivalent, you have an infinite number of these things to work with, so it…

If you're going to use a key space in the trillions, and partitioned and sparsely populated rather than sequential... isn't that just reinventing what the UUID already is? A UUID is just a 128-bit integer, with creation algorithms designed to partition that space by things that already have enough entropy to need no further synchronization. What you're proposing sounds like roll-your-own-UUID, which might be similarl…

Don't try to compare this to rolling your own crypto. The stakes are nowhere near the same for IDs as for crypto, and the stakes are the defining feature of the "don't roll your own crypto" meme.

Re: Things you should do now (2011)

#105

Post by MrCapybara »

marcosdumay wrote: post #52
chromatin wrote: post #30

Earlier quoted context omitted.

The reason (other than "don't expose integer PK externally") people say you should use integer as PK and UUID as a secondary/external facing id is that conventional B-tree indexing of UUID is not as efficient as B-tree indexing of autoinc integers in most databases. However if you want any sort of efficient lookup on the external key (UUID), your database still needs an index on the UUID, and you are back at square o…

Odds are very big that the set of externally visible entities is much smaller than the set of database entities. That is, unless you decide to put the same interface into your database and your API, what is not rare for OOM-only programmers to do, but always ends in tears.

What OOM means in this context? I assume it's not Out Of Memory?

Re: Things you should do now (2011)

#106

Post by deckard1 »

chromatin wrote: post #30
dkarp wrote: post #28

Earlier quoted context omitted.

integer ids are still often used internally for database primary keys with UUIDs being the done thing for external interfaces. Personally I've never experienced the "whole class of bugs" that starting with a big integer is supposed to solve. I'm not using PHP so maybe that's why?

The reason (other than "don't expose integer PK externally") people say you should use integer as PK and UUID as a secondary/external facing id is that conventional B-tree indexing of UUID is not as efficient as B-tree indexing of autoinc integers in most databases. However if you want any sort of efficient lookup on the external key (UUID), your database still needs an index on the UUID, and you are back at square o…

> However if you want any sort of efficient lookup on the external key (UUID), your database still needs an index on the UUID, and you are back at square one.

Well. Many systems already do a form of this. They store a session ID (the browser cookie) in something like redis which maps to an internal database id which is often incremented. The internal database ids are never seen outside the DB.

In this case it's fine because the external IDs are ephemeral (relatively) and centralization is a hard criteria (you typically can't have two people creating an account with the same user name, or having one email address linked to multiple record IDs, etc.).

This is really why these discussions are pointless without specifics and a concrete system.

Re: Things you should do now (2011)

#107

Post by deckard1 »

marcus_holmes wrote: post #51
mherrmann wrote: post #39

Earlier quoted context omitted.

Actually, afaik uuids are pseudo-random and can thus absolutely collide in theory. Collision is solved by every db backend out there.

UUID collision is not possible in practice. You can absolutely code in the absolute knowledge that your application will not generate 2 identical UUID's ever. The odds are astronomical. You have bigger concerns. And yes, every DB backend has solved collision. But as I said, it's useful to be able to generate ID's in code sometimes. This is possible with UUID's and not possible with integers.

just make sure you have everything configured correctly on your system if using UUIDs:

https://github.com/ramsey/uuid/issues/80

In the types of systems that need UUIDs there is probably no easy way to check for collisions. The prospect of mystery data corruption with no ability to trace it down frightens the hell out of me.

The only reason that issue was reported is because someone was actually doing the collision checking. That's not going to be the norm in UUID systems. Think about it.

Re: Things you should do now (2011)

#108

Post by marcosdumay »

MrCapybara wrote: post #105
marcosdumay wrote: post #52

Earlier quoted context omitted.

Odds are very big that the set of externally visible entities is much smaller than the set of database entities. That is, unless you decide to put the same interface into your database and your API, what is not rare for OOM-only programmers to do, but always ends in tears.

What OOM means in this context? I assume it's not Out Of Memory?

Ops, I misstyped ORM.

Re: Things you should do now (2011)

#109

Post by coldtea »

teddyh wrote: post #14
faeyanpiraat wrote: post #13

Earlier quoted context omitted.

Sigh..

What? Did I miss a memo or something? I would have hoped to get an actual answer to my question instead of rhetorical sighs (and downvotes). Note: I am not a native English speaker.

>What? Did I miss a memo or something?

Yes, there was never some contract that we all signed or some thing some majority of us formally voted that says "we're not supposed to call it a blacklist/whitelist anymore.

Just what some random groups decided and enforced at their own domains (companies, orgs, etc.).

It's also based on an American preoccupation with race issues, seeing everything through it's own guilt-ridden history, concerns not relevant to other parts of the world (where code is written and English is also spoken, as first or second language for IT).

The connotations of black/white s terms have nothing to do with slavery or blacks, the term blacklist was first used (recorded) in an English theater play, as the list of the enemies of the kind (black alluding to shady, dark motives, etc, not to skin color), and its common colloquial use in the 20th century was also not about blacks or had anything to do with slavery: it was the list where employees put union members, strikers, etc not to hire.

It's better for people in the US to concentrate on fixing actual racial issues (from incarceration rates and cop shootings, to school funding, redlining and loan access) than to play with words to pat itself in the back.

People all over the world have used black/white to certain things (sometimes the inverse too, e.g. in some asian cultures white is associated with death), and it has nothing to do with the US practicing slavery, seggregation, and racism to blacks.

We use those terms with some connotations for centuries before blacks were sold as slaves to pick your cotton, even at times when slaves where whites working for other whites (as in Ancient Persia, Greece, the Roman Empire, feudal times, and so on).

Re: Things you should do now (2011)

#110

Post by coldtea »

circlefavshape wrote: post #44
corty wrote: post #18

Earlier quoted context omitted.

Yes, but why? How? I'm a non-native-speaker as well, and these things might be obvious to you, but they aren't to me. Is it a "should not use it", "must not use it", "maybe" or "it's fashionable"? How bad would it be if I accidentially use it, more like a four-letter-word or more like "well, he's a foreigner, he doesn't know"?

It totally depends on context and the culture of the people you are communicating with. Safest option is not to use it

Not very safe either, since then you impose an american preoccupation based on their history and modern politics to the rest of the world...
Post reply on HN