3 ms·

> FriendlyId v3.x prevented this by keeping the slug sequence in a separate place in the database, and operating upon it within a transaction, thus guaranteeing

> FriendlyId v3.x prevented this by keeping the slug sequence in a separate place in the database, and operating upon it within a transaction, thus guaranteeing atomic access to reading, incrementing, and updating the slug sequence. So he created a 'solution' where no problem exists. At least, TIL an new word: slug.

zaptheimpaler 14y ago
>So, the problem is since friendly_id v4, the gem no longer guarantees two really important principles: >No guarantee that we're the only person reading this value, right now >No guarantee that the ID we'll choose will be unique a few µseconds from now. The problem exists in the newer version. If anything, the developers created a problem where none existed, not him. They traded consistency for simplicity without a clear mention of the possible race conditions.
- ExpiredLink 14y ago
  >> No guarantee that the ID we'll choose will be unique a few µseconds from now. That's why you let the database atomically create the next id for you. There is no problem. You either get the next unique id or you have to try again.
  - dasil003 14y ago
    So the obtuse point your trying to make is that slugs are unnecessary and we should just use an auto-increment or uuid? Sorry, but slugs serve a real purpose, so your solution is only a solution in the sense that walking is a solution for a broken down car.
    - codebeaker 14y ago
      > Sorry, but slugs serve a real purpose, so your solution is only a solution in the sense that walking is a solution for a broken down car. This doesn't replace slugs, at all - the slugs are still generated, this replaces the SQL unique sequencer. The SQL sequencer which isn't universally supported, and has a different API on every platform.. many modern applications have Redis or a similar atomic structure store which could provide an interim solution, short of building a purpose built ticket provisioning system such as that employed by Flickr.

zaptheimpaler 14y ago

>So, the problem is since friendly_id v4, the gem no longer guarantees two really important principles: >No guarantee that we're the only person reading this value, right now >No guarantee that the ID we'll choose will be unique a few µseconds from now. The problem exists in the newer version. If anything, the developers created a problem where none existed, not him. They traded consistency for simplicity without a clear mention of the possible race conditions.

ExpiredLink 14y ago
>> No guarantee that the ID we'll choose will be unique a few µseconds from now. That's why you let the database atomically create the next id for you. There is no problem. You either get the next unique id or you have to try again.
- dasil003 14y ago
  So the obtuse point your trying to make is that slugs are unnecessary and we should just use an auto-increment or uuid? Sorry, but slugs serve a real purpose, so your solution is only a solution in the sense that walking is a solution for a broken down car.
  - codebeaker 14y ago
    > Sorry, but slugs serve a real purpose, so your solution is only a solution in the sense that walking is a solution for a broken down car. This doesn't replace slugs, at all - the slugs are still generated, this replaces the SQL unique sequencer. The SQL sequencer which isn't universally supported, and has a different API on every platform.. many modern applications have Redis or a similar atomic structure store which could provide an interim solution, short of building a purpose built ticket provisioning system such as that employed by Flickr.