Incrementing IDs instead of UUIDs?

[Janiczek]

What's the reason of using random UUIDs for entities instead of, for example, integers (as you'd see in SQL databases)? Is your only concern guaranteeing that your ID-generating function never repeats itself?

Considering integers:

• creating an atom with the counter would probably suffer from the same singleton state bug as #1 - I don't think you could have a guarantee that somebody wouldn't reset! the atom back to 0 (which would cause you to start overwriting the entities). Maybe some good encapsulation would solve this, but nah, after the change from global atoms to everything in the system, this would feel like a kludge.
• having another key in system (something like {:last-entity-id 12}) would guarantee no repeating IDs but would cause you to change the API: (create-entity system) has the problem of need to return both the changed system and entity ID. You'd probably have to create a function (get-last-entity-id), which is not very elegant.

I think I understand the reason for the use of UUIDs now: you can create new one without knowing the last one. Is that correct? Or is the reason different?

[markmandel]

Pretty much.

Honestly, I didn't think about it a great deal - I just went 'I need a unique id' and so I went with UUID as it was the least amount of work without having to worry about anything else.

Also, if you end up sending the id across a network (say) or another system, you don't have to worry about collisions (or you don't to such a small extent that it's basically the same). For the same reason I've used UUIDs in databases as well. Whereas incrementing IDs can easily collide across systems.

[Janiczek]

True. So the UUIDs guarantee "never" returning the same ID, across different systems, without any knowledge of what IDs are already generated. With integers the machinery would be much trickier.

---

BTW, I've tried using Brute in a ClojureScript project - basically the only two things that needed rewrite were:

(defn create-uuid []
  ;; http://stackoverflow.com/a/2117523/403702
  (let [template "xxxxxxxx-xxxx-4xxx-yxxx-xxxxxxxxxxxx"
        f #(let [r (Math/floor (* (rand) 16))
                 v (if (= % \x) r (bit-or (bit-and r 0x3) 0x8))]
             (.toString v 16))]
    (.replace template (js/RegExp. "[xy]" "g") f)))

and using (Math/floor ...) instead of the math.numeric-tower one, and using type instead of class.

Maybe "Brute-JS" can live in its own repo, but the number of changes is so small that I think it could be in the main repo, thanks to cljx. Would you be interested in that (a pull request, in a separated issue, of course), or do you have your own plans with JS version? (DataScript or something)

[markmandel]

I've no plans for a Clojurescript version at this time - I'd be more than happy to have a pull request. Something like cljx sounds like a perfect fit.

The interesting problem would be running the Midje tests in Clojurescript. Maybe something like Midje-lite could be used to bridge the gap.

I've been meaning to set up a wercker test environment for a while now, so this would give me the impetus.

[Janiczek]

I'll try to figure the tests and cljx out and create a pull request then :)