No creo que sea susceptible a la "race condition" (si entiendo bien a lo que te referis con eso). Con esta solución, podés tener el índice único como vos querés en el campo login. Es decir la base de datos te asegura que no haya dos personas con el mismo login por más que tengas varios procesos. Creo que no necesitas un custom validates. Con el validates_uniqueness_of te alcanza, sólo le tenés que indicar que no tenga en cuenta los nil.
S. 2010/3/26 NachoKB <[email protected]> 2010/3/26 Juan Martin Buceta <[email protected]> Podés crear a los usuarios con el login en null guardando el login tentativo en otra columna, y luego en el activate setear el login. está buena, me gusta (con un custom validates, claro) igualmente me parece que también es susceptible a la race condition... 2010/3/28 Nicolás Sanguinetti <[email protected]>: > 2010/3/26 NachoKB <[email protected]>: >> Estimados, >> tengo un caso frente al que me quede sin ideas prácticamente. >> >> Simplificando, tengo un model User que tiene una validación de uniqueness >> sobre el atributo login. Ahora bien, debido a que la unica forma de >> garantizar unicidad es con un index unique en la base, lo agregué >> (básicamente, ActiveRecord no puede garantizar la unicidad por un tema de >> concurrencia). >> >> Ahora mi problema es que la registración de usuario tiene dos pasos >> (primero se crea y luego se verifica). Mi problema es que necesitaría que no >> valide como erroneo en el caso que exista otro usuario con el mismo login, >> pero estando ese usuario aun no activado (digamos "pendiente"). O sea, >> quisiera que la verificación de existencia la realice no sobre toda la >> tabla, sino, por ejemplo, usando un named_scope. >> >> Rápidamente cree un método "validates_uniqueness_of_with_named_scope" para >> que la verificación del "exists?" la realice sobre un named scope (si fue >> especificado), idéntico en todo lo demás al "validates_uniqueness_of" >> standard, y funcionó bárbaro. >> >> Por supuesto, en este caso aunque el validates sea correcto, la base de >> datos detecta duplicación por el index unique... >> >> No se me ocurre manera de soportar este caso sin perder el resguardo del >> index unique... ¿alguna idea? ¿cómo lo hacen? >> >> Perdón la longitud para explicar algo tan simple :D. >> >> nachokb > > Che, y para qué querés confirmar el email de los usuarios? Tenés > tantos spammers registrándose que es un problema? Porque sino, no hay > cosa más molesta que registrarme a un sitio y tener que ir a fijarme > en el mail y hacer el confirmation mientras puteo porque es un sitio > QUE NO NECESITA CONFIRMARME PARA NADA MÁS QUE PARA SATISFACER UN > CAPRICHO SIN SENTIDO. > > Er, yo que sé, a mi me gusta registrarme en un sitio y automáticamente > poder usarlo. Capaz que si tenés problemas de spam o alguna función > del sitio es medio sensible (mandarle mensajes a otros usuarios, o > recibir notificaciones por email, ponele), podés hacer que solo esas > acciones estén restringidas a usuarios confirmados, entonces > básicamente me dejás entrar al sitio y usarlo hasta que de veras > necesitás mi email (o confirmar que soy una persona, e igual, > confirmar el email es un método pésimo para detectar spammers hoy en > día, es bien fácil scriptear algo que confirme mails si estuvieses > haciendo un spambot…) > > Y pensá también esto: te registrás y podés usar el sitio > inmediatamente. Genial! Lo usás, jugás un rato, te aburrís, salís. Y > después saltás a la ventana del email y ves que tenés un mail del > sitio para confirmarte (pero que no te trancó para nada en las > funciones básicas que querías hacer), hacés click para sacarte eso de > arriba, y te lleva a una página diciendo "ahora podés hacer estas > otras cosas, gracias por confirmarte" y bam, con un poco de suerte y > un buen diseño, el usuario está involucrado en tu sitio, jugando con > las cosas nuevas que le diste. Double win :) > > Yo que sé, yo en lo posible saco los flows de confirmación de los > sitios, nunca son necesarios. > > -foca >> _______________________________________________ >> Ruby mailing list >> [email protected] >> http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar >> >> > _______________________________________________ > Ruby mailing list > [email protected] > http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar > _______________________________________________ Ruby mailing list [email protected] http://lista.rubyargentina.com.ar/listinfo.cgi/ruby-rubyargentina.com.ar
