Ulrich Windl wrote: >>>> Michael Ströder<[email protected]> schrieb am 21.02.2015 um 20:06 in > Nachricht <[email protected]>: >> 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.
smime.p7s
Description: S/MIME Cryptographic Signature
