From: Robert Klemme Date: 2010-10-07T23:55:39+09:00 Subject: Re: Maximum length of array#hash On Thu, Oct 7, 2010 at 4:31 PM, Jim Burgess wrote: >> Having said that, what's the point in storing a hash code in a >> database table?  Basically this is redundant information and when >> querying you would want to check for the key fields anyway because >> hash codes are by far not unique.  So the hash code is not helpful >> during querying.  Jim, what's the point? > I'm using it to prevent double data submission in my rails app. > When a user submits my form, I create an array of everything he/she has > submitted. Then I create a hash-code of this array and compare it with > the hash code of the last successful submission (which is stored in the > db table). > This effectively eliminates double data submission (i.e. a user pressing > submit multiple times or using the back button and resubmitting). > > I looked high and low for an effective method to stop double data > submission and couldn't find anything that worked well, thus I came up > with this idea. > > If this is a backwards method of preventing double data submission and I > am missing something obvious, please do let me know. The RDBMS way to do it would be to define a unique index (or use the primary key for that) in the table which simply prevents duplicate insertions. I am not a web developer but I am sure the discipline has invented methods to avoid this already. My simple approach would be to add a hidden field to the form with a string I generate (just a silly example "#{rand 37}:#{Time.now.to_f}"). I would then store *that* value in the table if necessary. You could as well use a submit counter that you store in your session. Then you could detect duplicate submission without going to the DB which is slower than a check in memory. http://www.echoecho.com/htmlforms07.htm I would certainly not rely on #hash because that is too fragile. Kind regards robert -- remember.guy do |as, often| as.you_can - without end http://blog.rubybestpractices.com/