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 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.
