Rails - Jun 2006 - ADVICE: Generating unique identifiers for later DB insertion

All,

I have an ActiveRecord object that I need to be able to uniquely 
identify _before_ I actually save the object (I may not end up saving 
the object based on conditions).  This is because I want to use the ID 
in another context (a file name in the filesystem).

Depending on conditions, I may or may not need to do a lot of stuff 
between the time that I generate the object ID and actually make the 
decision to save the object.  I am toying with the idea of using an ID 
generator for this object.

I wanted to get some input on using an "external to the DB" generator
to
create my unique ids for insertion into the DB.

Am I overthinking this?  Should I just do the insert as soon as possible 
to have the DB generate my ID, use the ID as I need to, and then either 
delete that record (or rollback a transaction) later if it turns out 
that the record shouldn''t be saved after all?

Hope this makes sense.

Thanks,
Wes

-- 
Posted via http://www.ruby-forum.com/.

On 6/22/06, Wes Gamble <weyus@att.net> wrote:
> Am I overthinking this?  Should I just do the insert as soon as possible
> to have the DB generate my ID, use the ID as I need to, and then either
> delete that record (or rollback a transaction) later if it turns out
> that the record shouldn''t be saved after all?
Yes, and no.  I generally recommend not tying anything like this to
the primary key of a record.  It''s much better to create an extra
column (VARCHAR of appropriate size) and use that as the file key.  It
will still be saved with the record and you can still let Rails do
what it wants and maintain full control of the "external" stuff (file
names, etc).

I would recommend maybe a randomized MD5 hash system or such (similar
to the algorighm Rails uses to make sessions).  UserID (or something)
+ Now (DateTime) + Random Number run through the MD5 hashing method to
generate a string you can use for the file name and data column.  Your
ActiveRecord model subclass will happily work with the data and save /
retrieve it from the database.  It also gives you an almost gauranteed
unique value (you can always run a search of the database and
regenerate if it''s not unique--if you''re paranoid)


-Curtis

Curtis Spendlove wrote:
> On 6/22/06, Wes Gamble <weyus@att.net> wrote:
>> Am I overthinking this?  Should I just do the insert as soon as
possible
>> to have the DB generate my ID, use the ID as I need to, and then either
>> delete that record (or rollback a transaction) later if it turns out
>> that the record shouldn''t be saved after all?
> 
> Yes, and no.  I generally recommend not tying anything like this to
> the primary key of a record.  It''s much better to create an extra
> column (VARCHAR of appropriate size) and use that as the file key.  It
> will still be saved with the record and you can still let Rails do
> what it wants and maintain full control of the "external" stuff
(file
> names, etc).
> 
> I would recommend maybe a randomized MD5 hash system or such (similar
> to the algorighm Rails uses to make sessions).  UserID (or something)
> + Now (DateTime) + Random Number run through the MD5 hashing method to
> generate a string you can use for the file name and data column.  Your
> ActiveRecord model subclass will happily work with the data and save /
> retrieve it from the database.  It also gives you an almost gauranteed
> unique value (you can always run a search of the database and
> regenerate if it''s not unique--if you''re paranoid)
> 
> 
> -Curtis
Curtis,

I agree.  Thanks for the advice.  I ended up using user_id + 
Time.now.to_f.to_s (with the fractional seconds I''m pretty confident 
that the identifier will be unique).

Wes

-- 
Posted via http://www.ruby-forum.com/.

On Jun 22, 2006, at 6:17 PM, Wes Gamble wrote:
> Curtis Spendlove wrote:
>> On 6/22/06, Wes Gamble <weyus@att.net> wrote:
>>> Am I overthinking this?  Should I just do the insert as soon as  
>>> possible
>>> to have the DB generate my ID, use the ID as I need to, and then  
>>> either
>>> delete that record (or rollback a transaction) later if it turns
out
>>> that the record shouldn''t be saved after all?
>>
>> Yes, and no.  I generally recommend not tying anything like this to
>> the primary key of a record.  It''s much better to create an
extra
>> column (VARCHAR of appropriate size) and use that as the file  
>> key.  It
>> will still be saved with the record and you can still let Rails do
>> what it wants and maintain full control of the "external"
stuff (file
>> names, etc).
>>
>> I would recommend maybe a randomized MD5 hash system or such (similar
>> to the algorighm Rails uses to make sessions).  UserID (or something)
>> + Now (DateTime) + Random Number run through the MD5 hashing  
>> method to
>> generate a string you can use for the file name and data column.   
>> Your
>> ActiveRecord model subclass will happily work with the data and  
>> save /
>> retrieve it from the database.  It also gives you an almost  
>> gauranteed
>> unique value (you can always run a search of the database and
>> regenerate if it''s not unique--if you''re paranoid)
>>
>>
>> -Curtis
>
> Curtis,
>
> I agree.  Thanks for the advice.  I ended up using user_id +
> Time.now.to_f.to_s (with the fractional seconds I''m pretty
confident
> that the identifier will be unique).
Take a look at the "uuid" gem. It will generate unique numbers on a  
system and is already packaged up as a gem.

cr

On Thursday, June 22, 2006, at 11:48 PM,  wrote:
>
>On Jun 22, 2006, at 6:17 PM, Wes Gamble wrote:
>
>> Curtis Spendlove wrote:
>>> On 6/22/06, Wes Gamble <weyus@att.net> wrote:
>>>> Am I overthinking this?  Should I just do the insert as soon as
>>>>>>> possible
>>>> to have the DB generate my ID, use the ID as I need to, and
then
>>>>>>> either
>>>> delete that record (or rollback a transaction) later if it
turns out
>>>> that the record shouldn''t be saved after all?
>>>
>>> Yes, and no.  I generally recommend not tying anything like this to
>>> the primary key of a record.  It''s much better to create
an extra
>>> column (VARCHAR of appropriate size) and use that as the file
>>
>>>key.  It
>>> will still be saved with the record and you can still let Rails do
>>> what it wants and maintain full control of the "external"
stuff (file
>>> names, etc).
>>>
>>> I would recommend maybe a randomized MD5 hash system or such
(similar
>>> to the algorighm Rails uses to make sessions).  UserID (or
something)
>>> + Now (DateTime) + Random Number run through the MD5 hashing
>>
>>>method to
>>> generate a string you can use for the file name and data column.
>>>>> Your
>>> ActiveRecord model subclass will happily work with the data and
>>>>> save /
>>> retrieve it from the database.  It also gives you an almost
>>
>>>gauranteed
>>> unique value (you can always run a search of the database and
>>> regenerate if it''s not unique--if you''re
paranoid)
>>>
>>>
>>> -Curtis
>>
>> Curtis,
>>
>> I agree.  Thanks for the advice.  I ended up using user_id +
>> Time.now.to_f.to_s (with the fractional seconds I''m pretty
confident
>> that the identifier will be unique).
>
>Take a look at the "uuid" gem. It will generate unique numbers on
a
>system and is already packaged up as a gem.
>
>cr
>
>_______________________________________________
>Rails mailing list
>Rails@lists.rubyonrails.org
>http://lists.rubyonrails.org/mailman/listinfo/rails
MySQL also has a UUID() function, but this approach may not be database  
agnostic.

_Kevin

-- 
Posted with http://DevLists.com.  Sign up and save your mailbox.