title: Generating UUIDs for IndexedDB keys?
body: <p>The W3C spec for IndexedDB defines <a href="http://www.w3.org/TR/IndexedDB/#dfn-key-generator" rel="nofollow">a key generator</a> as:</p>
  
  <blockquote>
    <p>A key generator generates a monotonically increasing numbers [sic] every time a key is needed.</p>
  </blockquote>
  
  <p>Now, it seems (to me) that a common use case for IndexedDB (or, for that matter, any of the HTML5 client-side storage options: WebSQL, localStorage etc.) would be apps designed to work offline (in conjunction with HTML5 ApplicationCache).</p>
  
  <p>In this scenario, a <em>disconnected</em> web application might generate new objects/records in it's local data store that are later synced to a centralised database when a connection to the server becomes available.</p>
  
  <p>Further, any application where multiple clients sync to the <em>same</em> centralised database typically requires a mechanism to prevent ID collisions.</p>
  
  <p>UUID (or GUID) is a good choice, as it enables unique key generation without any central coordination. By contrast, <em>"monotonically incrementing numbers"</em> is a poor solution (unless each client is "seeded" with a starting value that is unlikely to collide with other users).</p>
  
  <p>I find it surprising that the IndexedDB spec does not specify (or even allow for future support of) alternate key generators, such as a UUID generator. Some may suggest that the answer is simply not to use IndexedDB's builtin key generator at all, instead have your application generate it's own keys.</p>
  
  <p>However, while there are plenty of Javascript-based UUID generators available, many of them seem to be based on Math.random() which has known limitations in terms of it's <em>randomness</em>, so might not be a good choice if absolute unique keys must be guaranteed.</p>
  
  <p>A native UUID generator provided by the IndexedDB implementors would (presumably) be more robust and perform better than a script implemented/imported by the application; one would think.</p>
  
  <p>So am I missing something here, or is this a missed opportunity by the W3C IndexedDB working group?</p>