[Dovecot] PATCH: mysql authentication

[Matthew Reimer]

Timo Sirainen wrote:
 >
> On Saturday, Aug 30, 2003, at 02:16 Europe/Helsinki, Matthew Reimer 
> wrote:
> 
>> Here's a patch that implements mysql authentication. I started with 
>> the pgsql files and tweaked them to use mysql instead. It works for 
>> me, but there might be a couple of memory leaks. I'm welcome to 
>> suggestions on how to clean it up so it can be committed.
> 
> Thank you. I'll look at it more closely later, but it looked fine with 
> a quick look.
> 
> It would be nice to be able to use asynchronous database lookups. I'm 
> not sure how easy that is with MySQL, of if it's possible at all. With 
> PostgreSQL it looked annoyingly difficult so I haven't done it yet.
 >
 > Synchronous calls anyway mean that there's only one SQL statement
 > executing at a time and that may slow down the authentication if
 > there's a _lot_ of users logging in constantly. If that's a problem,
 > growing auth_count should help at least some. It specifies the number
 > of auth processes that respond to the authentication queries.
 >
 > And some day I'll probably move the sql stuff into separate lib-sql
 > and have only a single sql authenticator..

I'm not sure what you mean by asynchronous database lookups. Do you mean 
you'd like to be able to fire off a db lookup and then come back later 
to get the results? Like blocking vs non-blocking? I've pasted what may 
be relevant mysql documentation below in case it might help answer the 
question.

N db handles could be allocated, giving us N simultaneous lookups.

Matt

---

 From http://www.mysql.com/doc/en/C_API_function_overview.html:

There are two ways for a client to process result sets. One way is to 
retrieve the entire result set all at once by calling 
mysql_store_result(). This function acquires from the server all the 
rows returned by the query and stores them in the client. The second way 
is for the client to initiate a row-by-row result set retrieval by 
calling mysql_use_result(). This function initialises the retrieval, but 
does not actually get any rows from the server.

In both cases, you access rows by calling mysql_fetch_row(). With 
mysql_store_result(), mysql_fetch_row() accesses rows that have already 
been fetched from the server. With mysql_use_result(), mysql_fetch_row() 
actually retrieves the row from the server. Information about the size 
of the data in each row is available by calling mysql_fetch_lengths().

After you are done with a result set, call mysql_free_result() to free 
the memory used for it.

The two retrieval mechanisms are complementary. Client programs should 
choose the approach that is most appropriate for their requirements. In 
practice, clients tend to use mysql_store_result() more commonly.

An advantage of mysql_store_result() is that because the rows have all 
been fetched to the client, you not only can access rows sequentially, 
you can move back and forth in the result set using mysql_data_seek() or 
mysql_row_seek() to change the current row position within the result 
set. You can also find out how many rows there are by calling 
mysql_num_rows(). On the other hand, the memory requirements for 
mysql_store_result() may be very high for large result sets and you are 
more likely to encounter out-of-memory conditions.

An advantage of mysql_use_result() is that the client requires less 
memory for the result set because it maintains only one row at a time 
(and because there is less allocation overhead, mysql_use_result() can 
be faster). Disadvantages are that you must process each row quickly to 
avoid tying up the server, you don't have random access to rows within 
the result set (you can only access rows sequentially), and you don't 
know how many rows are in the result set until you have retrieved them 
all. Furthermore, you must retrieve all the rows even if you determine 
in mid-retrieval that you've found the information you were looking for.

--- end