Configuring for external database support.

[azerwyn]

I'm starting this discussion to facilitate an exchange of thoughts and experience with configuring, compiling, and coding with external databases.

Presently, fluffos provides support for MySQL(mariadb), Postgress, and SQLite.

There is also still some really dusty code in there from the beginning of time for mSQL (note the distinction from MySQL). I don't advocate anyone use mSQL for anything in the 21st century; it doesn't have transaction logic or rollback.

I don't have any bias against any of the others; although, I admit to less experience with Postgress. I typically like to run with compiled support for both MySQL and SQLite3 -- each for different reasons.

Configuration (adm/dist/fluffos/src/CMakeLists.txt):

option(PACKAGE_DB "db package" ON)
set(PACKAGE_DB_MYSQL "1" CACHE STRING "DB Type for Mysql")
set(PACKAGE_DB_POSTGRESQL "" CACHE STRING "DB Type for POSTGRESQL")
set(PACKAGE_DB_SQLITE "2" CACHE STRING "DB Type for SQLITE")
set(PACKAGE_DB_DEFAULT_DB "1" CACHE STRING "Default DB Handle")

EFUNS (adm/dist/fluffos/src/packages/db/db.spec):

int db_close(int);
int db_commit(int);
int db_connect(string, string, string | void, int | void);
mixed db_exec(int, string);
mixed *db_fetch(int, int);
int db_rollback(int);
string db_status(void);

At present, there is little/no external database support in Lima. To assuage any fears, unlike other mudlibs that force database usage on prospective new adopters, I think the code support for external databases in Lima should be deliberately lite and entirely optional.

In the early days, the hard part of working with external databases (like external anything) was getting off the blank page. I'd like future adopters to not have to struggle to get off that blank page.

I have plenty of successful code I've used in the past that I'm willing to port; when I have time (after I get the ^domains/school/* rebased). That said, I think it is a good living topic for everyone to knock around ideas. What examples might you like to see?

Again, I don't think it is adopter friendly to have external database usage a requirement and I'm not suggesting such in any way. So, while we might brainstorm possibilities, try to remember the mission of a distribution mudlib. How can we be a rising tide instead of raising a single boat?

[tsathoqqua]

I think it makes good sense for people wanting to adopt a database approach for some functionality to have an easier time. I think you're also onto something around it perhaps shouldn't be required right now for people to use. I'm still thinking that database will be needed for auction house support, so we might as well move down this street at least a bit.

I'm not sure what can be done effectively with database support for player/wizard/shell files? Does it even make sense in those cases? I'm thinkling it makes more sense when you need to collect statistics or see across the mudlib for something - you know things databases are good at?

Would it be possible to have a module for the AUCTION_D (that doesn't exist yet), which would use files for data if no database support enabled or database if that was enabled? (#ifdef USE_DATABASE)? Just a thought.

# Compile the driver
rm -rf build
mkdir build
cd build
 cmake .. \
     -DPACKAGE_UIDS=OFF \
     -DPACKAGE_DB=ON

The issue with this is that it creates a hard dependency on MySQL or similar on the server. We probably need to modify the build procedure a bit. I compiled the driver on the LIMA server with the above, but there's still an underlying issue.

Please provide any good ideas 👍 I think we should move down this path 👍

^std/>@db_connect()
## ------- /trans/tmp/exec.c:8
## Too few arguments to 'db_connect'.
  mixed exec_foo(){ return db_connect();

It's compiled and in the driver now.