httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian McCallister <>
Subject Re: [Discuss] mod_lua and database connectivity
Date Fri, 04 Jan 2013 17:25:52 GMT
On Thu, Jan 3, 2013 at 11:05 PM, Daniel Gruno <> wrote:

> 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.

It is still a method on the server, not the request, even if you get passed
a request.

> > ...
> > 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'.

Implied semantics matter a LOT in API design.

> >
> > 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.

An API which returns (foo, err) should be error checked on the error, not
the foo. This style of API will sometimes return a foo in a bad state, and
an err to let you know. In your example this is fine, I am just being a
pedant because if an API is designed a certain way, we shoul duse it that
way :-)

> >
> > 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.

View raw message