Re: back-sql contributions deployment plan (was: back-sql with postgresql)

[Dmitry Kovalev <mitya@seismic.geol.msu.ru>]

Hello!

LoОc TREGOUкT wrote:

>         Hello,
>
>   It's my first message on this list and i hope
> this is the good place and you'll be able to understand me
> (I'm french ).

As far as I can tell (being Russian), everything is fine ;)

>
>
> I have been enjoyed to learn openldap can access a backend SQL.
> I use postgreSQL for a long time and i would have it as backend for
> openldap.

be shure you made right choice - I'm a little tired to warn about this, but you
should read FAQs and lists concerning usage of postgres as general-purpose
backend...

>
> I've used the following mail as beginning for the SQL data
> (backsql_create and test ).
> http://www.openldap.org/lists/openldap-bugs/200101/msg00036.html
>
> The modification of search.c seem to be not very portable .
> postgreSQL does not support "SELECT DISTINCT hard_value" but other
> RDBMS do not support "cast (hard_value as text)"
>
> The following works fine for both postgreSQL and mySQL (I don't have
> Oracle or mssql).

that's fine, thanks. Unfortunately, right now I have not much spare time, so I
cannot review your nor elder patches thoroughly, to ensure that we don't loose any
previously working platforms... As you could see, currently several people expressed
some will to contribute significant improvements to logic which I had no time/chance
to implement myself.

So, right now I gratefully await for the contributions as patches to current CVS
version (preferrably following current coding style as much as possible), and plan
to review them all and offer some deployment plan here on the list.

I can recall five major branches that we need to integrate in the following order:

1) Sam Drake's big list of improvements, including more SQL independency, and a lot
more discussed improvements in logic
2) postgres support, probably rewritten reusing (1) and syncronizing with new
database structure (based on patches by you, Eric Hofman, and other folks - see
archives)
3) SQL access wrapping, to screen back-sql from communication library used,
initially using ODBC; maybe along with conn pooling (possibly using some code/ideas
by Tomas Arredondo)
4) wrapper implementation in OCI, #ifdefed and configured alternative to ODBC
implementation (several folks have expressed readiness to contribute to OCI
implementation - Eric T. Blue, Tomas and others - see archives)
5) support for schema-dependent callbacks along with general mapping schema - see
discussions (Eric said that he "likes it" - it possibly means that he will
contribute this eventually :)

also
6) synching docs, samples and support for all other databases and testing
(unfortunately, this also needs volunteers, because otherwise these will freeze
until I solve my time problems)


According to this preliminary plan, we all are waiting for good news (patches) from
Sam primarily :)

WBW, Dmitry