Pierre-Arnaud Marcelot wrote:
> I'd love to do option #2 but this is something we can not do as the
> project I'm working on should not have any impact on the underlying
> applications except the application which exposes the model and
> discusses with the storage.
>
> I can't do option #1 as it the aim of the project... ;)
>
> I think we'll _just_ need to integrate the handling of the incremented
> IDs in the application we're re-writing (searching for the next
> available id and then insert the entry once we've figured out what
> value to use).
> The idea is also to keep the existing API for compatibility reasons,
> but deprecate a few elements in the model and additionally provide a
> *cleaner* API that applications could use for a future migration.
This is a form of #2 (make the client not require the LDAP server to
implement small positive integer unique ID generation).
It won't work in a replicated environment, (a variant of the scheme
where you build a your own distributed id allocation service would fix
this), but you may not have that requirement.
|