feat(Core/DB): Enable modules to have their own database pools/connections

[UndeadRogue]

Changes Proposed:

This PR proposes changes to:

• Core (units, players, creatures, game systems).
• Scripts (bosses, spell scripts, creature scripts).
• Database (SAI, creatures, etc).

tl;dr This should heavily unblock modules like playerbots from needing its own fork as all the database stuff it has to do in the core can now be done in the module

This is a proof of concept. There's a (limited) discussion here: #21302

One of the primary reasons that modules like playerbots need their own fork of azerothcore-wotlk is that it's not currently possible for a module to have:

• Their own database connection pool
• Use their own schema
• Define prepared statements

The underlying issue is that DatabaseWorkerPool is templated and cannot be statically linked during compilation of a module

This PR add addresses that while trying to be as unobtrusive as possible.

A module can now define their own database connection which is automatically part of a pool. This unblocks modules from the various limitations I mentioned above.

Sample implementation inside a modulke

header

#ifndef TIMETRAVEL_DATABASE_H
#define TIMETRAVEL_DATABASE_H

#include "ModuleDatabasePool.h"
#include "MySQLConnection.h"

enum TimeTravelDatabaseStatements
{
    TIMETRAVEL_INS_SNAPSHOT,
    TIMETRAVEL_INS_SPELL,
    TIMETRAVEL_SEL_SNAPSHOT,
    TIMETRAVEL_DEL_SNAPSHOT,
    MAX_TIMETRAVELDATABASE_STATEMENTS
};

class TimeTravelDatabaseConnection : public MySQLConnection
{
public:
    typedef TimeTravelDatabaseStatements Statements;

    TimeTravelDatabaseConnection(MySQLConnectionInfo& connInfo);

    void DoPrepareStatements() override;
};

class TimeTravelDatabasePool : public ModuleDatabasePool
{
protected:
    MySQLConnection* CreateConnection(MySQLConnectionInfo& connInfo) override;
};

extern std::unique_ptr<TimeTravelDatabasePool> TimeTravelDatabase;

void InitializeTimeTravelDatabase();

#endif

cpp

#include "TimeTravelDatabase.h"

std::unique_ptr<TimeTravelDatabasePool> TimeTravelDatabase;

void TimeTravelDatabaseConnection::DoPrepareStatements()
{
    PrepareStatement(TIMETRAVEL_INS_SNAPSHOT, "INSERT INTO character_timetravel (guid, timestamp, level, progression) VALUES (?, ?, ?, ?)", CONNECTION_ASYNC);
    PrepareStatement(TIMETRAVEL_INS_SPELL, "INSERT INTO character_timetravel_spells (guid, timestamp, spell_id, spec) VALUES (?, ?, ?, ?)", CONNECTION_ASYNC);
    PrepareStatement(TIMETRAVEL_SEL_SNAPSHOT, "SELECT timestamp, level, progression FROM character_timetravel WHERE guid = ? ORDER BY timestamp DESC", CONNECTION_SYNCH);
    PrepareStatement(TIMETRAVEL_DEL_SNAPSHOT, "DELETE FROM character_timetravel WHERE guid = ? AND timestamp = ?", CONNECTION_ASYNC);
}

TimeTravelDatabaseConnection::TimeTravelDatabaseConnection(MySQLConnectionInfo& connInfo)
    : MySQLConnection(connInfo)
{
    m_stmts.resize(MAX_TIMETRAVELDATABASE_STATEMENTS);
}


MySQLConnection* TimeTravelDatabasePool::CreateConnection(MySQLConnectionInfo& connInfo)
{
    return new TimeTravelDatabaseConnection(connInfo);
}

void InitializeTimeTravelDatabase()
{
    const char* envDbString = std::getenv("AC_TIMETRAVEL_DATABASE_INFO");
    std::string dbString = envDbString ? envDbString : sConfigMgr->GetOption<std::string>("TimeTravelDatabase.Info", "");

    if (dbString.empty())
    {
        LOG_ERROR("module", "TimeTravelDatabase.Info not specified in config!");
        return;
    }

    uint8 asyncThreads = sConfigMgr->GetOption<uint8>("TimeTravelDatabase.WorkerThreads", 1);
    uint8 synchThreads = sConfigMgr->GetOption<uint8>("TimeTravelDatabase.SynchThreads", 1);

    TimeTravelDatabase = std::make_unique<TimeTravelDatabasePool>();
    TimeTravelDatabase->SetConnectionInfo(dbString, asyncThreads, synchThreads);

    if (TimeTravelDatabase->Open() == 0)
    {
        LOG_ERROR("module", "Failed to open TimeTravel database!");
        return;
    }

}

AI-assisted Pull Requests

Important

While the use of AI tools when preparing pull requests is not prohibited, contributors must clearly disclose when such tools have been used and specify the model involved.

Contributors are also expected to fully understand the changes they are submitting and must be able to explain and justify those changes when requested by maintainers.

• AI tools (e.g. ChatGPT, Claude, or similar) were used entirely or partially in preparing this pull request. Please specify which tools were used, if any.

Yes, claude to generate some of the more repetitive parts based on the existing implementation and help debug issues when I was compiling

Issues Addressed:

• Closes

SOURCE:

The changes have been validated through:

• Live research (checked on live servers, e.g Classic WotLK, Retail, etc.)
• Sniffs (remember to share them with the open source community!)
• Video evidence, knowledge databases or other public sources (e.g forums, Wowhead, etc.)
• The changes promoted by this pull request come partially or entirely from another project (cherry-pick). Cherry-picks must be committed using the proper --author tag in order to be accepted, thus crediting the original authors, unless otherwise unable to be found

Tests Performed:

This PR has been:

• Tested in-game by the author.
• Tested in-game by other community members/someone else other than the author/has been live on production servers.
• This pull request requires further testing and may have edge cases to be tested.

How to Test the Changes:

• This pull request can be tested by following the reproduction steps provided in the linked issue
• This pull request requires further testing. Provide steps to test your changes. If it requires any specific setup e.g multiple players please specify it as well.

Known Issues and TODO List:

• [ ]
• [ ]

How to Test AzerothCore PRs

When a PR is ready to be tested, it will be marked as [WAITING TO BE TESTED].

You can help by testing PRs and writing your feedback here on the PR's page on GitHub. Follow the instructions here:

http://www.azerothcore.org/wiki/How-to-test-a-PR

REMEMBER: when testing a PR that changes something generic (i.e. a part of code that handles more than one specific thing), the tester should not only check that the PR does its job (e.g. fixing spell XXX) but especially check that the PR does not cause any regression (i.e. introducing new bugs).

For example: if a PR fixes spell X by changing a part of code that handles spells X, Y, and Z, we should not only test X, but we should test Y and Z as well.

[UndeadRogue]

There were basically two options here:

1. Remove templates from DatabaseWorkerPool
2. Re-implement the core functionality in a way that can be statically linked in modules

DatabaseWorkerPool is used so much inside AzerothCore that it is both a huge task and potentially massive blast radius for issues if the implementation is changed

By leaving the original implementation completely unchanged, this enables modules to use the functionality without potentially breaking a bunch of stuff inside azerothcore itself. This PR only adds functionality that is available in modules, it does not even get used by the core

If this implementation sucks, it'll only affect modules that implement it and cant break the core.

[UndeadRogue]

Since DBUpdater was coupled to DatabaseWorkerPool it made it impossible to use in a module with the new pool implementation, I made an adapter that allows it to be used with either the new or old implementation.

While this is a change to the core, hopefully it's acceptable because it's such a minor change to some arguments and a very simplistic wrapper