On Tue, 5 May 2020 at 10:26, Rowan Tommins <rowan.coll...@gmail.com> wrote:
> On Tue, 5 May 2020 at 08:52, Peter Bowyer <phpmailingli...@gmail.com> > wrote: > > > > > On Tue, 5 May 2020 at 07:38, Niklas Keller <m...@kelunik.com> wrote: > > > >> Rowan Tommins <rowan.coll...@gmail.com> schrieb am Mo., 4. Mai 2020, > >> 10:59: > >> > Although the name sounds similar, I don't think UUID would be a good > >> > replacement for uniqid(). In my experience, it's used for things like > >> > generating ID attributes for HTML elements, or suffixes for table > >> names, or > >> > even file names; applications that really just need a few alphanumeric > >> > characters that are different each time. > >> > >> Seems like UUIDs would be a good fit for all of these. > >> > > > > For file names, absolutely. In many cases they have to be unique across > > all processes, and that's important. For the others I say a UUID is only > a > > good replacement if taking a substring of a UUID is going to be unique. > > > > > As well as being nearly 3 times as long as the current uniqid() output, a > UUID is generally formatted with hyphens, which may be disallowed or > require careful quoting in various contexts. If you have to strip those > out, or otherwise manipulate the result to fit the use case, you've failed > at the original aim of having a single function that doesn't need further > processing. (Leaving aside the fact that we don't actually have any UUID > functions in core.) > > Regards, > -- > Rowan Tommins > [IMSoP] > The same notion here. UUID's and random_bytes sometimes are overkill, too slow or you can just exhaust the random source. I have a use-case where I needed exactly the way uniqid worked (with more_entropy = true) - a serial incrementing random value that I needed to create for 20-30 thousand items in one request. It was fast, efficient and there was absolutely no need to have a truly random value. And it needed to be human-readable easily because it was also sent via SMS in some cases. So in my opinion, a better replacement for uniqid is needed - have it generate a bigger string with more entropy and better underline algorithm, but it being time-based should be a thing stiff. And do not call it a "random_string" or something, cause it's not that :) Thanks! -- Arvīds Godjuks +371 26 851 664 arvids.godj...@gmail.com Skype: psihius Telegram: @psihius https://t.me/psihius
