httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian McCallister <bri...@skife.org>
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 <rumble@cord.dk> 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.
>
>

Mime
View raw message