{"issue":{"state":"closed","pull_request":{"diff_url":null,"html_url":null,"patch_url":null},"milestone":null,"user":{"avatar_url":"https://secure.gravatar.com/avatar/383fe45aca4dec367d997410fb904b3b?d=https://a248.e.akamai.net/assets.github.com%2Fimages%2Fgravatars%2Fgravatar-140.png","gravatar_id":"383fe45aca4dec367d997410fb904b3b","url":"https://api.github.com/users/gedankenstuecke","login":"gedankenstuecke","id":674899},"assignee":null,"updated_at":"2011-11-15T13:24:41Z","labels":[],"closed_at":"2011-11-15T13:24:41Z","comments":5,"url":"https://api.github.com/repos/norman/friendly_id/issues/180","body":"Hi,\r\nwe're using friendly_id (4.0.0.beta14) with the history-feature enabled on our project, together with resque for managing queues and found that some jobs are failing with *PGError: ERROR: duplicate key value violates unique constraint \"index_friendly_id_slugs_on_slug_and_sluggable_type\" : INSERT INTO \"friendly_id_slugs\" (\"slug\", \"sluggable_id\", \"sluggable_type\", \"created_at\") VALUES ('rs696974', 1676331, 'Snp', '2011-11-08 17:04:02.299340') RETURNING \"id\"*\r\n\r\nThis happened as soon as an object was supposed to be saved in this resque-job. After a bit of bug hunting I found the problem: \r\n\r\nSome actions in our application trigger multiple jobs on the same object that – if the queue is empty enough – are worked on at the same time as we have multiple resque-workers (with different queues) running in parallel. By chance it can happen that 2 jobs trigger the save-action at more or less the same time. This is fine with Rails/Postgres in general, as it blocks such stuff. \r\n\r\nBut it is not fine with friendly_id as it does not perform updates on the friendly_id_slugs-table if the combination of (object-ID & slug) are already in the table. Instead the old entry gets deleted and a new one is created:\r\n\r\n```\r\ndef build_slug\r\n  return unless should_generate_new_friendly_id?\r\n  # Allow reversion back to a previously used slug\r\n  slugs.where(:slug => friendly_id).delete_all\r\n  slugs.build :slug => friendly_id\r\nend\r\n```\r\nSee https://github.com/norman/friendly_id/blob/master/lib/friendly_id/history.rb#L71 \r\n\r\nIf those two save-actions are performed in fast succession it can happen that *worker A* has already performed deleting and creating the new slug-entry while *worker B* had nothing to delete but went on trying to create the new entry. Which then fails as *worker A* was some milliseconds faster. \r\n\r\n### Real world example: \r\nThe timestamp of an entry in the friendly_id_slugs-table: 2011-11-08 17:04:02.151681\r\nThe timestamp of the same entry where the save-transaction failed: 2011-11-08 17:04:02.299340 \r\n\r\n## Possible solution?\r\nNone that are really obvious, but what about updating entries instead of deleting/creating anew?","html_url":"https://github.com/norman/friendly_id/issues/180","title":"Duplicate Key Value problems by using history and parallel processing","number":180,"id":2177850,"created_at":"2011-11-08T18:56:44Z"},"action":"closed"}