The only reason to ask the database for a newly-inserted record's ID, for sequential numeric IDs, is because the database maintains the sequence and only the database can get the next number in the sequence.
But when using UUIDs, there is no reason to ask the database for a newly-inserted record's ID. Instead, the application can generate these UUIDs itself. This is, for example, what Hibernate and Mongoid do. On Tuesday, August 7, 2012 8:53:01 AM UTC-4, Ken Collins wrote: > > > I suspect that many people have been working successfully with uuid, guid, > or any other db-specific unique identifier data type for years now. I know > this has been the case in the SQL Server adapter. So finding these > implementations for hints would be a great start. Here are some links to my > work in the SQL Server adapter. > > *Wiki Article* > http://git.io/Ttb6mg > > *Implementation & Test Details* > > https://github.com/rails-sqlserver/activerecord-sqlserver-adapter/blob/master/lib/active_record/connection_adapters/sqlserver/database_statements.rb#L186-192 > > https://github.com/rails-sqlserver/activerecord-sqlserver-adapter/blob/master/test/schema/sqlserver_specific_schema.rb#L80-89 > > https://github.com/rails-sqlserver/activerecord-sqlserver-adapter/blob/master/test/cases/specific_schema_test_sqlserver.rb#L161 > > So there are a few things going on here. A summary: > > 1) SQL Server has a notion of unique identifiers where one is random and > the other sequential. One is faster, the other more secure, etc. Which is > better for a column primary key is debatable I think. Especially since > sequential is not even sequential per table, but per system. > > 2) It is really easy to setup a schema where the database champions > assigning a new unique identifier. However, getting that key back on > create/insert is a bit tricky since most low level connection modes do not > treat unique identifier columns as real primary keys. Hence if you let the > db generate the value, an insert would have to be followed by another > crafted select. The SQL Server supers up to ActiveRecord's > #last_inserted_id and falls back to SCOPE_IDENTITY() which is fine for > normal primary keys, but I do not know of a way to do the same (even > assuming I reflected on the table having unique identifier or not) to get > the random string that is a uuid column. A show stopper in itself. > > 3) The challenges of #2 are the reason I tell people in the wiki article > that it is much easier if you assign the unique identifier in a simple call > back. > > For these reasons, I am not seeing a way that ActiveRecord can champion a > datatype like this at a low level. It seems to me to have always supported > unique identifiers in simple patterns and that may be good enough. Thoughts? > > > - Ken > > On Aug 7, 2012, at 2:17 AM, Chris Lloyd wrote: > > (Cross post from #7278 <https://github.com/rails/rails/issues/7278>) > > Now that ActiveRecord supports uuid datatypes > (#6713<https://github.com/rails/rails/issues/6713>) > I suspect that having UUID instead of auto-incrementing primary keys will > become fairly popular. It's already possible to do this yourself but > perhaps it should be built into ActiveRecord? > > I'm happy to contribute a patch but was wanting to solicit feedback on > wether this is wanted and if anybody had ideas on how the configuration > should go. > > Chris > > > -- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Core" group. To view this discussion on the web visit https://groups.google.com/d/msg/rubyonrails-core/-/_oRJSJtuVHEJ. To post to this group, send email to rubyonrails-core@googlegroups.com. To unsubscribe from this group, send email to rubyonrails-core+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/rubyonrails-core?hl=en.
