On 01/06/2013 07:21 PM, Daniel Gruno wrote:
On 01/06/2013 04:23 PM, Stefan Fritsch wrote:
On Sun, 6 Jan 2013, Daniel Gruno wrote:
-- Regular prepared statement creation:
local prepped, err = db:prepare(SELECT * FROM `tbl` WHERE `id` = %s)
if not err then
local result, err =
On 01/06/2013 12:16 AM, Sean Conner wrote:
It was thus said that the Great Daniel Gruno once stated:
With regards to how :query should work, this could either be done
synchronously, wherein all rows are fetched at once, or async where rows
are fetched as needed. The sync way is rather easy,
On Sun, 6 Jan 2013, Daniel Gruno wrote:
Now I just have to take a good look at how to rewrite the prepared
statement stuff, and I believe I'll have a decent proposal ready for
commit :)
I am a bit late in the discussion, but maybe you also want to support
using statements that have been
On 01/06/2013 04:23 PM, Stefan Fritsch wrote:
On Sun, 6 Jan 2013, Daniel Gruno wrote:
Now I just have to take a good look at how to rewrite the prepared
statement stuff, and I believe I'll have a decent proposal ready for
commit :)
I am a bit late in the discussion, but maybe you also want
Implied semantics matter a LOT in API design.
+1
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
On 01/05/2013 10:49 AM, Igor Galić wrote:
Implied semantics matter a LOT in API design.
+1
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
It was thus said that the Great Daniel Gruno once stated:
With regards to how :query should work, this could either be done
synchronously, wherein all rows are fetched at once, or async where rows
are fetched as needed. The sync way is rather easy, but could fill up
more memory than needed,
On Thu, Jan 3, 2013 at 11:05 PM, Daniel Gruno rum...@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
Hello, fellow dev@ people, it's time for my monthly mod_lua rambling!
This time, I have set my eyes on creating bindings for the apr_dbd
features and mod_dbd in httpd. The purpose of this would be to both
enable people to easily use databases for Lua scripts, as well as lua
modules (hooks) in a
On Thu, Jan 3, 2013 at 5:32 AM, Daniel Gruno rum...@cord.dk wrote:
-
Connecting to a database:
-
function handler(r)
local db, error = r:dbopen(mod_dbd) -- Open a mod_dbd connection
Shouldn't this be a method on the server representation,
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
http://www.keplerproject.org/luasql/manual.html
-Brian
On Thu, Jan 3, 2013 at 4:57 PM, Brian McCallister bri...@skife.org wrote:
On Thu, Jan 3, 2013 at 5:32 AM,
Maybe you need this: https://github.com/zhaozg/mod_luaex
Example on http://kkhub.com
2013/1/4 Brian McCallister bri...@skife.org
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
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
13 matches
Mail list logo
