Hacker News Reader

Comment by phzbOx | Hacker News Reader

Would using only a CID be a solution?

From the server perspective, it stores the real ID and the CID given by the client. In the extremely rare case where CID could be duplicated, the server could send back an error with an unique CID and the client would update itself.

That way, we're sure the ID is always unique on the server, but the client simply use a cid. In fact, the 'cid' could even be abstracted away by calling it ID. I.e. the server has 2 ids, the server one and the client one.. the client doesn't need to know the server-side one.

View on HN

Sure, if you want to get fancy you can always do something fancier.

But in many apps, your server-side IDs are auto-incrementing MySQL or Postgres ids, or even a Flickr-style ticketing ID server. You really don't want your DB to be worrying about what are essentially transient JS/HTML references.

> "In the extremely rare case where CID could be duplicated, the server could send back an error with an unique CID and the client would update itself."

That's exactly the catch.

If you still need to consider CID collisions and write code to handle a potentially-different canonical server ID, there's no conceptual or complexity savings. You're not doing 'only' a CID; you're doing all the same work.

Well, I don't want to go into deep maths but the chance of creating the same cID is infinitesimal.. so one doesn't have to manage this case graciously. I.e. Just refresh the page or make a soft refresh (clear the models and re-send the data from the db, which isn't huge since that part is already coded for the initial loading). It's not the same as if it had 1/10 chance and you had to be clever to fix it. I mean, even without this problem, it happens from time to time that the best software needs to refresh because of a small bug.

That might be a practical improvement for some applications. But at a framework level I don't see any clear reason to prefer that approach. Particularly as the savings evaporate for any applications that can't handle collisions 'less than graciously'.

And, personally, it still 'smells' to me. I know that's not an objective argument, but there it is. It feels like a particularly leaky abstraction that will end up causing more trouble than it spares.

edit: clarified sarcasm that looked ambiguous on second glance.

Reply on news.ycombinator.com