Version 4.38 adds inbuilt support for SQLite. See their homepage for more information about SQLite:
http://www.sqlite.org/
From their homepage: "SQLite is a software library that implements a self-contained, serverless, zero-configuration, transactional SQL database engine. SQLite is the most widely deployed SQL database engine in the world. The source code for SQLite is in the public domain."
The interface to scripting is only available under Lua scripting. It uses the LuaSQLite 3 library, described as "a Lua 5.1 wrapper for the SQLite3".
Documentation for the Lua SQLite3 interface is here:
http://luasqlite.luaforge.net/lsqlite3.html
The reason for doing this is to provide an easy-to-use, inbuilt mechanism for database access in MUSHclient. As described it is zero-configuration which means "SQLite does not need to be "installed" before it is used. There is no "setup" procedure. There is no server process that needs to be started, stopped, or configured.".
It is serverless, which means you do not need to install, start or configure a server before using it.
It is transactional, which means "All changes within a single transaction in SQLite either occur completely or not at all, even if the act of writing the change out to the disk is interrupted by a program crash, an operating system crash, or a power failure."
As the support for SQLite is built into MUSHclient's code itself, script writers (for version 4.38 onwards) can be assured that they can use the database features, regardless of the settings in the Lua "sandbox", or whether loading of DLLs is permitted.
SQLite databases are ordinary disk files, and thus could be stored in any convenient directory, such as the "worlds" folder, or some other suitable place. Alternatively you can use SQLite "memory" databases, for making use of database queries, without actually opening any files at all.
Advantages and disadvantages of a database
The main competitor to using a database in a MUD client situation, is to store "persistent" information either in the world file itself, as MUSHclient variables, or serialized to a plugin "state" file.
World variables
Plugin state files
SQLite database
Example
http://www.sqlite.org/
From their homepage: "SQLite is a software library that implements a self-contained, serverless, zero-configuration, transactional SQL database engine. SQLite is the most widely deployed SQL database engine in the world. The source code for SQLite is in the public domain."
The interface to scripting is only available under Lua scripting. It uses the LuaSQLite 3 library, described as "a Lua 5.1 wrapper for the SQLite3".
Documentation for the Lua SQLite3 interface is here:
http://luasqlite.luaforge.net/lsqlite3.html
The reason for doing this is to provide an easy-to-use, inbuilt mechanism for database access in MUSHclient. As described it is zero-configuration which means "SQLite does not need to be "installed" before it is used. There is no "setup" procedure. There is no server process that needs to be started, stopped, or configured.".
It is serverless, which means you do not need to install, start or configure a server before using it.
It is transactional, which means "All changes within a single transaction in SQLite either occur completely or not at all, even if the act of writing the change out to the disk is interrupted by a program crash, an operating system crash, or a power failure."
As the support for SQLite is built into MUSHclient's code itself, script writers (for version 4.38 onwards) can be assured that they can use the database features, regardless of the settings in the Lua "sandbox", or whether loading of DLLs is permitted.
SQLite databases are ordinary disk files, and thus could be stored in any convenient directory, such as the "worlds" folder, or some other suitable place. Alternatively you can use SQLite "memory" databases, for making use of database queries, without actually opening any files at all.
Advantages and disadvantages of a database
The main competitor to using a database in a MUD client situation, is to store "persistent" information either in the world file itself, as MUSHclient variables, or serialized to a plugin "state" file.
World variables
- Advantage: Easy to use - MUSHclient variables are saved when the world file is saved
- Disadvantages: Cannot store complex things, like tables or lists, without mucking around. Need to remember to save the world file or the variables are not saved.
Plugin state files
- Advantage: Easy to use - plugin variables are saved when the plugin is closed.
- Disadvantages: Potential for loss of data if the power fails at the exact moment the plugin state file is being saved. Possible loss of data if the plugin state file is not saved for a long time. Plugin state files are per-world, so you potentially duplicate information (like, lists of spells) between multiple worlds. Also can be slow to load when they get large.
SQLite database
- Advantages: Guaranteed data safety. Database is saved in a "complete" state. SQL is an industry standard language. Complex queries can be written to get at data in different ways. Large amounts of data (eg. thousands of mobs' history) can be stored, but quickly accessed as the database only has to be queried in part, not completely read into memory.
- Disadvantages: Can be slower if writing a lot of data, however if done in a transaction, this slowdown is minimized. SQL takes a bit of work to learn. More programming needed to write to, or read from, the database compared to the other methods.
Example
-- open database in memory
db = assert (sqlite3.open_memory())
-- create a table
assert (db:execute[[
CREATE TABLE players(
name varchar(50),
class varchar(50)
)
]])
-- add a few elements
list = {
{ name="Nick Gammon", class="mage", },
{ name="David Haley", class="warrior", },
{ name="Shadowfyr", class="priest", },
}
for i, p in pairs (list) do
assert (db:execute(string.format([[
INSERT INTO players
VALUES ('%s', '%s')]], p.name, p.class)
))
end
-- print all rows, the rows will be indexed by field names
require "tprint"
for row in db:nrows("SELECT * FROM players") do
print ("\n------ new row ---------\n")
tprint (row)
end
-- close database
db:close()
Output
------ new row ---------
"name"="Nick Gammon"
"class"="mage"
------ new row ---------
"name"="David Haley"
"class"="warrior"
------ new row ---------
"name"="Shadowfyr"
"class"="priest"