afbb161ac5de41a2079ba53c9555049e37118e7e Tim Kadom tkadom@skiptree.com http://github.com/tkadom/friendly_id/commit/0cfcde309b96bc718db204837a46098c8fcbec60 0cfcde309b96bc718db204837a46098c8fcbec60

2008-10-29T08:24:58-07:00

friendly id was using the record count to determine the next id for a generated slug. This algorithm does not take into account hat aged records might have been removed with the associated rake task. i.e. if we created three slugs from the same base text and had base-val-1, base-val-2, and base-val-3 as our slugs initially. We then run a removal of aged slugs, leaving only base-val-2, and base-val-3, we would generate a count of 2 slugs which share the same slug root. the count would then try to create a base-val-3 slug which would error out on uniqueness validation. I changed the algorithm so that it is not as efficient, but it will actually re-use values that have been deleted by iterating through the mathing base slugs until an open slot is found for the new slug. 7a755ac0f2ab4550baa98605769bc6aab2ca6d84 Tim Kadom tkadom@skiptree.com adc856237e74bc30e1dc5e4e039d7fe891ad29a8 Tim Kadom tkadom@skiptree.com http://github.com/tkadom/friendly_id/commit/afbb161ac5de41a2079ba53c9555049e37118e7e afbb161ac5de41a2079ba53c9555049e37118e7e

2008-10-29T04:27:00-07:00

adds chunking to friendly id generation to prevent out of memory errors on large data b25e75c467bbf1f6be7efe3bb5e6eb50292919c3 Tim Kadom tkadom@skiptree.com Tim Kadom tkadom@skiptree.com http://github.com/tkadom/friendly_id/commit/adc856237e74bc30e1dc5e4e039d7fe891ad29a8 adc856237e74bc30e1dc5e4e039d7fe891ad29a8

2008-10-09T15:22:44-07:00

initial check-in 5a0b8ab4687629267de0c8d94ee4c86661bb2b20 Tim Kadom tkadom@skiptree.com