httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel Gruno <rum...@cord.dk>
Subject Re: [Discuss] mod_lua and database connectivity
Date Fri, 04 Jan 2013 06:05:35 GMT
On 01/04/2013 12:57 AM, Brian McCallister wrote:
...
> Supporting luasql would be a big bonus, though I understand if goal is to 
> provide a "quick and dirty api which is backed by mod_dbd"
Quick and dirty makes it sound so...dirty. But yes, essentially, the
purpose is to provide very basic database features for those just
getting started or those who either cannot be bothered (we know who you
lot are!) or can't figure out how to use luasql or other external
libraries. I'd want mod_lua to be something you can sit down and get
started on without having to learn how to compile lua or install
libraries, BUT if you wanted/needed the extra capabilities that fx
luasql provides, you could simply switch. It is not in any way intended
as a full replacement, rather as a 'starter kit' so people load the
module and go 'okay, what can this mod_lua puppy do for me?" and not
have to think about the sometimes cumbersome process of extending Lua's
capabilities.

I suppose I can boil my reasoning down to two major points:
1) We have apr_dbd capabilities in httpd, so why not support it in Lua?
This would mean a much smaller foot print when using databases in
mod_lua compared to loading an external library into every VM.
2) We'd want something that can connect through mod_dbd, which is
unlikely to be supported by third party database libraries.


> Shouldn't this be a method on the server representation, not the request
> representation?
There is no server handle, only a request handle given to mod_lua
scripts, you should know that ;). The server handle is obtained through
the request handle, so all is well and good here.
> ...
> Hmm, if db here represents a handle, it should prolly be paired with
> acquire not open.

Semantics ;) but sure, we could call it 'acquire' instead of 'open'.
> 
> Check your errors :-)
I don't need to check errors, I just need to check whether 'rows' is a
table or a nil value in the case of an error. I could've checked if
'err' was anything, but the result is the same.
> 
> Also, be careful what you return, you don't want to the API to force you
> to realize all results from a query eagerly.
Currently, it works that way - it fetches everything at once, which I
grant can be something you may or may not want. I am considering adding
a metatable to the 'rows' object with an __index hook that fetches new
rows only when needed. Good call! I will hold off on this for a while
though, as there are some memory pool concerns. Imagine if one runs a
query and uses the request pool for fetching data, then waits till
another request comes through before iterating through the rows, that
would cause an error, unless the query was stored in the global server
pool, in which case it could not get released (and then I'd have to,
instead, use another pool for allocating memory, which would have to be
tied to the db object - so much to do!). The global pool option is what
lua-apr does with eeeeeverything, which is not something I'd want
mod_lua to do.


>     -- Run a prepared statement and inject values into it:
>     local rows, err = db:inject(r, "SELECT `name` FROM `tbl` WHERE `id` =
>     %u", 1234)
> 
> 
> 
> Hmm, I would expect an API like 
> 
> local pstmt, err = h:prepare("...")
> ... = pstmt:execute("hello", 7")
> -- or ... = pstmt:query("hello", 7")
> 
> or such style api. "Injecting" into implicit prepared statement is a
> strange api.
>  

Not necessarily. If the injection function stores a key/value pair of
injected statements and prepares them beforehand, then a subsequent call
using the same statement would just look up whether that statement has
already been prepared, and there would be no need to recompile. Though,
I do see the benefits of instead associating a prepared statement with a
tag of your own, so I will definitely consider this as well :)

Thanks for your feedback, it's very much appreciated!

With regards,
Daniel.


Mime
View raw message