Thanks for the feedback! 

WRT uuid-ossp, I was originally using Postgres.app (http://postgresapp.com), 
which it seems doesn't ship with this module 
(https://github.com/mattt/PostgresApp/issues/39) by default.  I was able to get 
it working by switching to the homebrew recipe.  I think Postgres.app is fairly 
popular for development/testing (Heroku recommends it 
(https://devcenter.heroku.com/articles/heroku-postgresql#local-setup)), so this 
may be a common issue.  That said, I think they should be able to fix it for OS 
X 10.8 if homebrew can make it work, and if we can at least allow nil, that 
will make it possible until then.

And, yeah, I just set up a UUID concern with a before_create hook.  In the end, 
though, I just switched to homebrew pg with uuid-ossp instead :P

I hadn't seen enable_extension yet, thanks for the tip.

I think I pretty much have the patch to accept nil as a valid setting, but I 
will have to double-check the tests and try to add some documentation before 
submitting a pull request.

--Chad


On Thursday, April 25, 2013 at 6:25 PM, Aaron Patterson wrote:

> On Wed, Apr 24, 2013 at 02:32:04PM -0700, Chad Moone wrote:
> > This commit adds support for using primary keys of type UUID in 
> > PostgreSQL: 
> > https://github.com/rails/rails/commit/bc8ebefe9825dbff2cffa29ff015a1e7a31f9812
> > 
> > This is *awesome*, however, I'm not sure I understand the intention with 
> > the default setting. Right now, it's doing:
> > 
> > def primary_key(name, type = :primary_key, options = {})
> > return super unless type == :uuid
> > options[:default] ||= 'uuid_generate_v4()'
> > options[:primary_key] = true
> > column name, type, options
> > end
> > 
> > I see two issues with this implementation:
> > 
> > 1. The uuid_generate_v4()function depends on a module (uuid-ossp), which 
> > is not always included in PostgreSQL distributions and which itself 
> > requires an external library (which seems to often have issues compiling, 
> > at least from some initial searching). The module also must be applied to 
> > each database individually (unless the user has already added it to their 
> > system template). So, unless a user has a) installed a pg distribution 
> > which includes this module, b) installed external library, c) set up their 
> > system template to always include this module in new databases, running 
> > rake db:migrate in a fresh checkout will always fail. For those reasons, 
> > it seems like an inappropriate default setting.
> > 
> 
> 
> You need to add "enable_extension 'uuid-ossp'" to your migrations so
> that when people migrate, the extension is loaded. Same with HStore.
> 
> > 2. So far as I can tell, there is no possible way to override this 
> > value, short a) specifying a different uuid function from the uuid-ossp 
> > module, or b) having installed another UUID library and specifying a 
> > function from that. You cannot specify default: 0 or default: 'NULL', 
> > of any value other than a valid UUID, because pg does not consider them 
> > valid entries for the type. default: nil will fail, because the method 
> > above will override it. You can pass an actual uuid as a string (
> > default: "eddad8c1-43ad-4851-944a-a6205d266e5d"), however this seems 
> > pretty non-standard.
> > 
> 
> 
> We can fix it so that "nil" is a valid setting. Can you write a patch?
> 
> > To me, it seems that the ideal is actually to default to generating the 
> > UUID in Rails (via SecureRandom.uuid), however I'm not entirely sure how to 
> > do this while still allowing for database-level defaults.
> > 
> 
> 
> Bingo. Using "uuid-ossp" is the cleanest solution I've found. If we
> fix the "nil" case, you could add a "before_save" hook that sets the id
> using `SecureRandom.uuid`, but it seems hacky, and you'd have to add the
> code to every model that wanted it.
> 
> > Also, I wasn't able to find any documentation on this anywhere, so either 
> > I'm missing it, or we need to add it.
> > 
> 
> 
> It needs to be added. ;-)
> 
> -- 
> Aaron Patterson
> http://tenderlovemaking.com/
> 
> -- 
> You received this message because you are subscribed to a topic in the Google 
> Groups "Ruby on Rails: Core" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/rubyonrails-core/PaQldWtV4O8/unsubscribe?hl=en.
> To unsubscribe from this group and all its topics, send an email to 
> [email protected] 
> (mailto:[email protected]).
> To post to this group, send email to [email protected] 
> (mailto:[email protected]).
> Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
> 
> 


-- 
You received this message because you are subscribed to the Google Groups "Ruby 
on Rails: Core" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.


Reply via email to