Legal seu post Nando, tenho usado uuid em um projeto e estou gostando bastante. Só uma coisa, acredito que não seja necessário definir um índice do campo uuid para garantir que ele seja único, já que todas as chaves primárias já são por definição únicas e not null.

Você tem toda razão. Atualizei o artigo removendo esta informação. ;)

Eu tinha tentado usar UUID no mysql uma vez, mas a gem que usei não gerava um string bonitinha na tabela, gera um binário bizarro.
Depois vou tentar usar essa, prefiro muito mais usar chave UUID do que usar inteiro com auto incremento.

Este post aplica-se somente ao PostgreSQL.

Sim cara, to ligado.
Só estou compartilhando a experiência ruim que tive com rails, UUID e mysql. :)
E que depois vou testar no postgresql.
Desculpe se não fui muito claro.

Tranquilo! :)

Apesar de ser remota a chance disso acontecer, mas e como tratar a duplicidade de registro? Ou simplesmente não trata?

Não é preciso tratar. Chaves primárias já tem um índice de unicidade. Caso uma uuid seja gerada de forma duplicada, uma exceção será lançada.

Nando, sei que será lançada uma exceção, mas pensando na usabilidade da aplicação, quanto mais diante de uma API, isso poderia trazer um transtorno para o usuário. Contudo, você conseguiu me responder. Por se tratar de algo muito remoto de acontecer, melhor não tratar e deixar que o próprio usuário faça uma nova tentativa. Obrigado pela sua resposta.

Dada a baixíssima probabilidade de colisão, eu diria para deixar para lá. No entanto, se você quiser mesmo "resolver" esse "problema", pode adicionar um begin..rescue que usa um retry para tentar salvar o registro novamente.

:clap: :clap: :clap:

O comentário que iria fazer.
Atualmente, para mim, as coisas estão assim: "melhor não tratar e deixar que o próprio usuário faça uma nova tentativa"

Nando, qual implementação você sugere usar para gerar esses identificadores? O Ember.js tem algum módulo pra isso?

Não, o Ember não tem nada built-in. Mas existem várias implementações por aí. Dá uma procurada no http://bower.io.

Fala Nado, tenho acompanhado seu blog a um tempo e sempre com posts bem explicativos. Parabéns. Quanto a suas experiências com o UUID como chave, seja elas no heroku, howtocode, etc, já se deparou com situações relacionadas queda de performance? ou algo que observou que valesse a pena ser comentado? abs

vale ressaltar que:

a- usar uuid v1 ou mesmo v4 como está no padrão não é possível indexar de forma otimizada, pois, a ordem dos bits 'por padrão' não é deterministica*

b- o uso de chave uuid v1 como PK tem que reordenar os bits para que seja "de forma incremental"

c- quando não se tem "uuid embutido" no banco de dados, pode, estar usando uma linguagem pra isso

d- o ideal eh que esse campo seja gerado via trigger

e- e que seja armazenado no formato binário, p.ex., "binary" 16

that's all folks!