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