Mailing List Archive

Aug 28, 2003, 3:38 AM

Post #2 of 14 (2283 views)

All hail Ilja!

I have one question though - any chance of using transactions?

Regards,

Chris

Ilja Booij wrote:

> Hi all,
>
> finally, the new database code is in CVS. It is totally untested (it
> compiles), and will be tested when I'm finished with an urgent project
> that has started this week. The new code can be found in the
> dbmail_2_0 CVS branch (you can take a look
> at the code and diffs without downloading by going to
> http://cvs.dbmail.org).
>
> * database code
> The following changes have been made:
> dbmysql.c and dbpgsql.c now only consist of functions which implement
> API specific functionality. db.c (new file) implements all database
> functions which used to be implemented by db??sql.c .
> The same goes for dbsearch??sql.c and dbmsgbuf??sql.c, which are now
> implemented by dbsearch.c and dbmsgbuf.c
>
> * Authentication
> The authentication code from dbauth??sql.c has been moved to a new
> auth/ directory. There are two C-files there. authsql.c which
> implements "classic" SQL authentication. authldap.c implements LDAP
> authentication as implemented by Aaron Stone (aaron@serendipity.cx).
> I've added a configure switch --with-auth-ldap which will compile
> dbmail with this LDAP code.
>
> * Query improvement
> In db.c some queries have been made "better" by putting the
> intelligence into the SQL query instead of the C-code
> (db_icheck_messages() is an example of this).
>
> * InnoDB
> Paul Stevens posted some better MySQL innoDB tables definitions to the
> dbmail@dbmail.org list, which have now taken the place of the old
> innoDB definitions.
>
> * Warnings
> The configure script now adds -W -Wall to the gcc flags. There are
> quite a lot of warnings currently (most have to do with
> unsigned<->signed conflicts), which have to be taken care of. I'd like
> the package to compile cleanly.
>
> * Doxygen
> To help developers to get a good view of the code, I've started
> documenting all functions with doxygen (www.doxygen.org) tags. For
> those of you who don't know doxygen, think of it as an improved
> JavaDoc, which makes hyperlinked HTML pages for all source files.
>
> * Website
> I hope to be able to update www.dbmail.org next week.
>
> * WARNING
> Again, this is alpha code. Please try it, look at the code, send your
> comments, etc. Don't use this in a production environment yet.
>
> cheers,
> Ilja Booij
> --
> IC&S
> Koningsweg 4
> 3582 GE UTRECHT
>
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev

Re: new database code [ In reply to ]

paul at nfg

Aug 28, 2003, 4:09 AM

Post #3 of 14 (2266 views)

Ilja Booij wrote:
> * Authentication
> The authentication code from dbauth??sql.c has been moved to a new auth/
> directory. There are two C-files there. authsql.c which implements
> "classic" SQL authentication. authldap.c implements LDAP authentication
> as implemented by Aaron Stone (aaron@serendipity.cx).
> I've added a configure switch --with-auth-ldap which will compile dbmail
> with this LDAP code.

Great. It builds with out a problem. Only issue I had was a missing
Makefile.in in /auth/

But from Aaron's description in one of his earlies emails, I get the
impression that some custom ldap-schema are being used. Is that so, and
if so, where-o-where is it ? Aaron ?

Also, are there any plans to incorporate TLS support in dbmail2. That is
to say: for connecting to mysql, or to the ldapserver, or in the
imap/pop servers themselves?

--
________________________________________________________________
Paul Stevens mailto:paul@nfg.nl
NET FACILITIES GROUP PGP: finger paul@nfg.nl
The Netherlands________________________________http://www.nfg.nl

Re: new database code [ In reply to ]

Aug 28, 2003, 4:13 AM

Post #4 of 14 (2272 views)

I have a question for the wise people of the world who use DBMail!

OpenLDAP has an SQL backend. DBMail talks to PostgreSQL and MySQL. Would
there be any point in getting DBMail to understand the schema OpenLDAP
uses (for performance mainly I'd guess).

Chris

Paul J Stevens wrote:

>
>
> Ilja Booij wrote:
>
>> * Authentication
>> The authentication code from dbauth??sql.c has been moved to a new
>> auth/ directory. There are two C-files there. authsql.c which
>> implements "classic" SQL authentication. authldap.c implements LDAP
>> authentication as implemented by Aaron Stone (aaron@serendipity.cx).
>> I've added a configure switch --with-auth-ldap which will compile
>> dbmail with this LDAP code.
>
>
>
> Great. It builds with out a problem. Only issue I had was a missing
> Makefile.in in /auth/
>
> But from Aaron's description in one of his earlies emails, I get the
> impression that some custom ldap-schema are being used. Is that so,
> and if so, where-o-where is it ? Aaron ?
>
> Also, are there any plans to incorporate TLS support in dbmail2. That
> is to say: for connecting to mysql, or to the ldapserver, or in the
> imap/pop servers themselves?
>
>
>
>
>

Re: new database code [ In reply to ]

Aug 28, 2003, 4:35 AM

Post #5 of 14 (2265 views)

Hi,

sorry, no transactions. I'd like for dbmail to use them, but currently
there is MySQL ISAM table support. These ISAM tables do not support
Transactions.

Anyone have any thoughts on why we should keep support for ISAM tables
in dbmail? Dropping this and going of innoDB only on MySQL seems like a
good idea to me.

cheers,
Ilja

On Thursday, Aug 28, 2003, at 12:38 Europe/Amsterdam, Chris Nolan wrote:

> All hail Ilja!
>
> I have one question though - any chance of using transactions?
>
> Regards,
>
> Chris
>
> Ilja Booij wrote:
>
>> Hi all,
>>
>> finally, the new database code is in CVS. It is totally untested (it
>> compiles), and will be tested when I'm finished with an urgent
>> project that has started this week. The new code can be found in the
>> dbmail_2_0 CVS branch (you can take a look
>> at the code and diffs without downloading by going to
>> http://cvs.dbmail.org).
>>
>> * database code
>> The following changes have been made:
>> dbmysql.c and dbpgsql.c now only consist of functions which implement
>> API specific functionality. db.c (new file) implements all database
>> functions which used to be implemented by db??sql.c .
>> The same goes for dbsearch??sql.c and dbmsgbuf??sql.c, which are now
>> implemented by dbsearch.c and dbmsgbuf.c
>>
>> * Authentication
>> The authentication code from dbauth??sql.c has been moved to a new
>> auth/ directory. There are two C-files there. authsql.c which
>> implements "classic" SQL authentication. authldap.c implements LDAP
>> authentication as implemented by Aaron Stone (aaron@serendipity.cx).
>> I've added a configure switch --with-auth-ldap which will compile
>> dbmail with this LDAP code.
>>
>> * Query improvement
>> In db.c some queries have been made "better" by putting the
>> intelligence into the SQL query instead of the C-code
>> (db_icheck_messages() is an example of this).
>>
>> * InnoDB
>> Paul Stevens posted some better MySQL innoDB tables definitions to
>> the dbmail@dbmail.org list, which have now taken the place of the old
>> innoDB definitions.
>>
>> * Warnings
>> The configure script now adds -W -Wall to the gcc flags. There are
>> quite a lot of warnings currently (most have to do with
>> unsigned<->signed conflicts), which have to be taken care of. I'd
>> like the package to compile cleanly.
>>
>> * Doxygen
>> To help developers to get a good view of the code, I've started
>> documenting all functions with doxygen (www.doxygen.org) tags. For
>> those of you who don't know doxygen, think of it as an improved
>> JavaDoc, which makes hyperlinked HTML pages for all source files.
>>
>> * Website
>> I hope to be able to update www.dbmail.org next week.
>>
>> * WARNING
>> Again, this is alpha code. Please try it, look at the code, send your
>> comments, etc. Don't use this in a production environment yet.
>>
>> cheers,
>> Ilja Booij
>> --
>> IC&S
>> Koningsweg 4
>> 3582 GE UTRECHT
>>
>> _______________________________________________
>> Dbmail-dev mailing list
>> Dbmail-dev@dbmail.org
>> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>
>
>
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev

Re: new database code [ In reply to ]

Aug 28, 2003, 4:41 AM

Post #6 of 14 (2272 views)

On Thursday, Aug 28, 2003, at 13:09 Europe/Amsterdam, Paul J Stevens
wrote:
> Ilja Booij wrote:
>> * Authentication
>> The authentication code from dbauth??sql.c has been moved to a new
>> auth/ directory. There are two C-files there. authsql.c which
>> implements "classic" SQL authentication. authldap.c implements LDAP
>> authentication as implemented by Aaron Stone (aaron@serendipity.cx).
>> I've added a configure switch --with-auth-ldap which will compile
>> dbmail with this LDAP code.
>
> Great. It builds with out a problem. Only issue I had was a missing
> Makefile.in in /auth/
fixed.
>
> But from Aaron's description in one of his earlies emails, I get the
> impression that some custom ldap-schema are being used. Is that so,
> and if so, where-o-where is it ? Aaron ?
The main reason I've put it in so that Aaron could test it. Aaron, if
you can post your ldap-schema, I'll put in the new branch.
> Also, are there any plans to incorporate TLS support in dbmail2. That
> is to say: for connecting to mysql, or to the ldapserver, or in the
> imap/pop servers themselves?
We've discussed TLS for imap/pop here at IC&S, and it's a feature we
would like to add.

cheers,
Ilja

Re: new database code [ In reply to ]

Aug 28, 2003, 4:44 AM

Post #7 of 14 (2273 views)

On Thursday, Aug 28, 2003, at 13:13 Europe/Amsterdam, Chris Nolan wrote:

> I have a question for the wise people of the world who use DBMail!
>
> OpenLDAP has an SQL backend. DBMail talks to PostgreSQL and MySQL.
> Would there be any point in getting DBMail to understand the schema
> OpenLDAP uses (for performance mainly I'd guess).
So, you'd like to use LDAP authentication, but then bypass that and use
the SQL-backend of the LDAP-server directly?
If this is what your asking then I would say: no there is no point. I'd
say, use the LDAP-API for LDAP and SQL for SQL. (I could point out the
reasons why, but I figure there pretty obvious to everyone).

cheers,
Ilja

Re: new database code [ In reply to ]

Aug 28, 2003, 4:46 AM

Post #8 of 14 (2267 views)

Hi,

ISAM and MyISAM are venerable but it looks as if even MySQL AB
themselves are relying heavily on InnoDB. The fact that we can have
foregin keys now with InnoDB is
a massive benefit (MyISAM won't get this until it's implemented for all
table types, which is slated for MySQL 5.0).

There is one advantage that MyISAM tables have, and that's their
FULLTEXT index capabilities.

Regards,

Chris

Ilja Booij wrote:

> Hi,
>
> sorry, no transactions. I'd like for dbmail to use them, but currently
> there is MySQL ISAM table support. These ISAM tables do not support
> Transactions.
>
> Anyone have any thoughts on why we should keep support for ISAM tables
> in dbmail? Dropping this and going of innoDB only on MySQL seems like
> a good idea to me.
>
> cheers,
> Ilja
>
> On Thursday, Aug 28, 2003, at 12:38 Europe/Amsterdam, Chris Nolan wrote:
>
>> All hail Ilja!
>>
>> I have one question though - any chance of using transactions?
>>
>> Regards,
>>
>> Chris
>>
>> Ilja Booij wrote:
>>
>>> Hi all,
>>>
>>> finally, the new database code is in CVS. It is totally untested (it
>>> compiles), and will be tested when I'm finished with an urgent
>>> project that has started this week. The new code can be found in the
>>> dbmail_2_0 CVS branch (you can take a look
>>> at the code and diffs without downloading by going to
>>> http://cvs.dbmail.org).
>>>
>>> * database code
>>> The following changes have been made:
>>> dbmysql.c and dbpgsql.c now only consist of functions which
>>> implement API specific functionality. db.c (new file) implements all
>>> database functions which used to be implemented by db??sql.c .
>>> The same goes for dbsearch??sql.c and dbmsgbuf??sql.c, which are now
>>> implemented by dbsearch.c and dbmsgbuf.c
>>>
>>> * Authentication
>>> The authentication code from dbauth??sql.c has been moved to a new
>>> auth/ directory. There are two C-files there. authsql.c which
>>> implements "classic" SQL authentication. authldap.c implements LDAP
>>> authentication as implemented by Aaron Stone (aaron@serendipity.cx).
>>> I've added a configure switch --with-auth-ldap which will compile
>>> dbmail with this LDAP code.
>>>
>>> * Query improvement
>>> In db.c some queries have been made "better" by putting the
>>> intelligence into the SQL query instead of the C-code
>>> (db_icheck_messages() is an example of this).
>>>
>>> * InnoDB
>>> Paul Stevens posted some better MySQL innoDB tables definitions to
>>> the dbmail@dbmail.org list, which have now taken the place of the
>>> old innoDB definitions.
>>>
>>> * Warnings
>>> The configure script now adds -W -Wall to the gcc flags. There are
>>> quite a lot of warnings currently (most have to do with
>>> unsigned<->signed conflicts), which have to be taken care of. I'd
>>> like the package to compile cleanly.
>>>
>>> * Doxygen
>>> To help developers to get a good view of the code, I've started
>>> documenting all functions with doxygen (www.doxygen.org) tags. For
>>> those of you who don't know doxygen, think of it as an improved
>>> JavaDoc, which makes hyperlinked HTML pages for all source files.
>>>
>>> * Website
>>> I hope to be able to update www.dbmail.org next week.
>>>
>>> * WARNING
>>> Again, this is alpha code. Please try it, look at the code, send
>>> your comments, etc. Don't use this in a production environment yet.
>>>
>>> cheers,
>>> Ilja Booij
>>> --
>>> IC&S
>>> Koningsweg 4
>>> 3582 GE UTRECHT
>>>
>>> _______________________________________________
>>> Dbmail-dev mailing list
>>> Dbmail-dev@dbmail.org
>>> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>>
>>
>>
>>
>> _______________________________________________
>> Dbmail-dev mailing list
>> Dbmail-dev@dbmail.org
>> http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>
>
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev

Re: new database code [ In reply to ]

Aug 28, 2003, 4:50 AM

Post #9 of 14 (2271 views)

I'd agree for the vast, vast majority of applications. Some weird admins
I know would love the feature. I guess the only option is to shoot Nerf
weapons at them. :-)

Ilja Booij wrote:

>
> On Thursday, Aug 28, 2003, at 13:13 Europe/Amsterdam, Chris Nolan wrote:
>
>> I have a question for the wise people of the world who use DBMail!
>>
>> OpenLDAP has an SQL backend. DBMail talks to PostgreSQL and MySQL.
>> Would there be any point in getting DBMail to understand the schema
>> OpenLDAP uses (for performance mainly I'd guess).
>
> So, you'd like to use LDAP authentication, but then bypass that and
> use the SQL-backend of the LDAP-server directly?
> If this is what your asking then I would say: no there is no point.
> I'd say, use the LDAP-API for LDAP and SQL for SQL. (I could point out
> the reasons why, but I figure there pretty obvious to everyone).
>
> cheers,
> Ilja
>
> _______________________________________________
> Dbmail-dev mailing list
> Dbmail-dev@dbmail.org
> http://twister.fastxs.net/mailman/listinfo/dbmail-dev

Re: new database code [ In reply to ]

Aug 28, 2003, 4:57 AM

Post #10 of 14 (2268 views)

On Thursday, Aug 28, 2003, at 13:46 Europe/Amsterdam, Chris Nolan wrote:

> Hi,
>
> ISAM and MyISAM are venerable but it looks as if even MySQL AB
> themselves are relying heavily on InnoDB. The fact that we can have
> foregin keys now with InnoDB is
> a massive benefit (MyISAM won't get this until it's implemented for
> all table types, which is slated for MySQL 5.0).
Foreign keys are pretty useful indeed. Waiting for MySQL 5.0 could take
quite long i guess ;)
>
> There is one advantage that MyISAM tables have, and that's their
> FULLTEXT index capabilities.
That's an important point for DBmail.. Hadn't thought of that.

cheers,
Ilja

Re: new database code [ In reply to ]

matthew at zeut

Aug 28, 2003, 12:12 PM

Post #11 of 14 (2278 views)

On Thu, 2003-08-28 at 07:57, Ilja Booij wrote:
> > There is one advantage that MyISAM tables have, and that's their
> > FULLTEXT index capabilities.
> That's an important point for DBmail.. Hadn't thought of that.

PostgreSQL supports full text search through a contrib module. Works
well from all reports I've hears. The postgresql website uses it to
search the mail archives.

Re: new database code [ In reply to ]

Aug 28, 2003, 3:31 PM

Post #12 of 14 (2271 views)

Hi Matthew,

Agreed, PostgreSQL's FULLTEXT search is just as funky (if not more so, I
don't have enough hands-on
experience to say) than MySQL's.

If only MySQL's FULLTEXT was external like PostgreSQL's! Then, we
wouldn't be having this MyISAM vs
InnoDB discussion.

Regards,

Chris

Matthew T. O'Connor wrote:

>On Thu, 2003-08-28 at 07:57, Ilja Booij wrote:
>
>
>>>There is one advantage that MyISAM tables have, and that's their
>>>FULLTEXT index capabilities.
>>>
>>>
>>That's an important point for DBmail.. Hadn't thought of that.
>>
>>
>
>PostgreSQL supports full text search through a contrib module. Works
>well from all reports I've hears. The postgresql website uses it to
>search the mail archives.
>
>_______________________________________________
>Dbmail-dev mailing list
>Dbmail-dev@dbmail.org
>http://twister.fastxs.net/mailman/listinfo/dbmail-dev
>
>

Re: new database code [ In reply to ]

xndbmail at xerus

Aug 28, 2003, 6:13 PM

Post #13 of 14 (2271 views)

On Thu, Aug 28, 2003 at 01:35:48PM +0200, Ilja Booij wrote:
> sorry, no transactions. I'd like for dbmail to use them, but currently
> there is MySQL ISAM table support. These ISAM tables do not support
> Transactions.
>
> Anyone have any thoughts on why we should keep support for ISAM tables
> in dbmail? Dropping this and going of innoDB only on MySQL seems like a
> good idea to me.

Any reason why it can't be determined at runtime whether or not to wrap
queries in a transaction?

xn

Re: new database code [ In reply to ]

Aug 28, 2003, 8:34 PM

Post #14 of 14 (2266 views)