chrisrink10 / luadb Goto Github PK

Configuration specified in, say, /etc/luadb/config.lua is not being read right now. Everything is hard-coded in the binary.

reqhandler.lua routes requests based on the request_uri, which can also contain query parameters. Consequently, any routes which include query parameters fail.

LuaDB is currently just loading every library into the global namespace when it spawns a new Lua state. This would be very performance intensive for implementations which involve a large number of incoming HTTP requests since it's likely each request would need it's own new state. Consider instead just pushing a single import function into the global namespace that application scripts can use to load the statically linked C libraries on-demand.

Several of the following items may make sense to be added to config.lua in case they change across web servers or operating systems:

• FastCGI environment prefix (default: "HTTP_")
• Expected number of FastCGI headers and variables
• Default FastCGI backlog
• Default device for FastCGI
• Log prefix (default: "luadb")
• Log location (default: "/var/log/luadb.log")
• etc.

Per the caveats listed on the main page of the LMDB docs:

Do not have open an LMDB database twice in the same process at the same time. 
Not even from a plain open() call - close()ing it breaks flock() advisory locking.

Right now, LuaDB runs everything in the main thread. When multithreading support is added, there is a high likelihood that two Lua scripts could be running with separate references to the same MDB_env which could cause locking issues as noted above.

We should create a global MDB_env object that is shared between Lua instances.

LuaDB uses getopt on POSIX systems, but has no alternative for Windows. For now, the argument parsing just... won't work.

Right now, all configuration settings are exclusively evaluated and stored as char *, but this makes them only suitable for things like paths which are always going to be strings.

Certain types of query string characters might cause issues with the current parser. The RFC that defines query strings technically permits a ; delimiter in addition to &, but the parser does not account for that.

They may not be useful.

For now, the query string comes as it's own string, but it's not parsed out into a usable format for calling scripts.

Right now, LuaDB stays in the foreground once it is started in FastCGI mode. This doesn't really make sense. It should fork itself into a background process.

LuaDB's uuid.c is referencing uuid_string_t, which is only included in the Apple/Darwin headers for uuid/uuid.h. Consequently, the compiler on Linux throws errors when it encounters this absurd type.

Fortunately, it looks like uuid_string_t is just a typedef for char[37], and the standard libuuid uses a 'uuid_unparse(uuid_t, char *)' function prototype anyway, so we can just fix this by using a char *.

Lua scripts would have to manually modify the package.path before calling require if the desired script is not in their include path. It would be nice if users could open LuaDB with a command line argument to specify additional include paths for the entire environment.

For systems which provide readline, LuaDB will compile with support for that library. However, since LuaDB does not provide it as a native dependency, Windows has no line editing support.

Lots of internal functions have lazy descriptions. Lots of headers are lacking full Doxygen comment blocks.

The MUMPS $ORDER function which is emulated by the lmdb.Transaction:order function does not return duplicated key nodes, rather it always returns the next unique key node in ordered iteration over the database.

This should be fixed.

Parsed query string keys and values are returned to users raw right now. These values should be parsed so + and %20 are converted to spaces and other hex values are reinterpreted as their intended value.

Query strings such as ?id=10&v=w&id=11&somename&lol=this+is+a+string are parsed into the following:

id = table: 0x1717870
v = w
somename&lol = this+is+a+string

We should honor any key-only types of query string parameters.

Title says it all.

We should not rely on application level code to check for stale entries in the reader table. A background thread should be created that runs with a configurable frequency calling mdb_reader_check.

Other popular Lua libraries will perform cycle detection when encoding from Lua tables. The library in LuaDB should do that too.

Right now, there is no easy way to define templates from LuaDB. Something like Mustache would be ideal.

The LuaDB json library's decode function is supposed to mark Lua tables with the metatable field _json_array on decode, but for some reason this fails. This means that JSON arrays are not properly re-encoded as arrays (i.e. the identity function of json.encode(json.decode(t)) == t for some table t does not hold).

Right now it's pretty painful to figure out what brought down the LuaDB FastCGI process. Some things are pushed into the web-server error log from stderr, but it would be better if LuaDB had it's own logs.

When encoding a Lua table to JSON, the json library module throws a Lua error and never completes. It appears that it pushes an extra string onto the stack at json.c:139 in the function lua_value_to_json and it never calls lua_pop to pop the extra value off the stack. This throws off lua_next and the table iteration fails.

For now, it appears that MinGW is throwing undefined reference to '_imp...' errors at the linker stage.

There are a few places where we use bool rather than int. API names are inconsistent. A style guide should be created and followed.

Because luadb_strndup uses strncpy rather than memcpy, it will fail to NUL terminate strings that are taken from larger character buffers (as is being done in query string parsing). Consequently, attempting to JSON encode the data generates UTF-8 errors (if it does not SEGFAULT) since string will almost certainly run into some crazy bytes.

Fix by swapping to use memcpy and manually NUL terminate.

Review code and LMDB documentation to verify that no illegal operations are permitted.

Right now, when the environment configuration values are loaded from config.lua, the code merely assumes that the value is going to exist. Instead, we should provide sensible defaults and defer to the Lua values if they are provided.

Likewise, proper error handling should be imposed so if the values in the Lua code are invalid for some reason, we won't use them (and won't crash :) ).

Integers are often reloaded as double/float values which are correctly integral (e.g. 1 is loaded as 1.0). This is annoying and counterintuitive. LuaDB already has a function in the json library which verifies if a number is integral in C, so we should generalize this and use it for similar purposes to verify that integers are correctly serialized and deserialized as such.

The only support for filesystem manipulation from LuaDB is from whatever rudimentary pieces Lua provides out of the box. We should implement LFS.

A package such as LuaSQL might do the trick.

FastCGI LuaDB processes are all single-threaded now. Explore threading options.

For some magical reason, libuuid just works on OS X without requiring an explicit linkage. However, this does not work on Linux.