Ulrich Windl wrote: >>>> Michael Ströder<michael@stroeder.com> schrieb am 21.02.2015 um 20:06 in > Nachricht <54E8D726.30503@stroeder.com>: >> Bernd May wrote: > [...] >>> You could also create a dummy user account that stores the next usable >>> gid/uid pair (which you acquired once with the previous algorithm) and >>> then query that account each time you create a new user, increase its >>> gid and uid values and create your new user. This assumes some kind of >>> conflict free numbering scheme of your users by which you can infer the >>> next free number pair automatically. >> >> The problem with id pool entries (kind of a sequence generator) is that ids >> might be consumed without being really used. Therefore for numeric ids it's > >> a >> better approach to search for all entries, use reverse server-side sorting >> and >> only query one result to get the highest id. > > But that's somewhat "performance-heavy" I guess. What could help here would be > transactions (actually nested transactions). Consume a UID/GID and assign it to > a new entry in one transaction. This would only help in case the second write operation fails. But the more likely problem is that the user might abort the use-case. Of course it depends when the client actually generates the id. In case of my web2ldap I present the generated id in the input form so the user could manually change it if needed. But the user might not hit the submit button. YMMV. Ciao, Michael.
Attachment:
smime.p7s
Description: S/MIME Cryptographic Signature