Database Bridges

Database Bridges

MST modules depend on database accessor interfaces rather than a specific storage engine. Provider factories register concrete accessors in Mst.Server.DbAccessors during server initialization.

Included Providers

Provider	Typical use
LiteDB	Local development, demos, small standalone deployments, and simple embedded persistence
MongoDB	Document-oriented production storage and horizontally managed MongoDB deployments
SqlSugar	SQL databases supported by the configured SqlSugar provider and dialect

Database bridge assemblies are opt-in and excluded from WebGL. Add only the provider assemblies and factories needed by the server scene.

Accessor Boundaries

Modules request focused interfaces such as:

• IAccountsDatabaseAccessor for accounts, service bindings, account blocks, and recovery data;
• IProfilesDatabaseAccessor for player profiles;
• IChatDatabaseAccessor for chat history;
• IAnalyticsDatabaseAccessor for analytics batches;
• ILeaderboardsDatabaseAccessor for leaderboard entries.

Register one intended implementation for each interface. Do not let unrelated factories compete to replace the same accessor during scene startup.

Provider Selection

Choose a provider based on deployment requirements rather than demo convenience:

• use LiteDB when one process owns the file and operational simplicity matters most;
• use MongoDB when document storage and managed scaling match the infrastructure;
• use SqlSugar when the project requires an existing relational database or SQL operations.

Each logical accessor should use its intended database or file configuration. Avoid opening the same LiteDB file through unrelated owners unless the provider explicitly shares one managed connection.

Configuration

Common provider arguments include:

-mstDatabaseProvider=MySql
-mstDatabaseConnectionString=Server=127.0.0.1;Database=game;Uid=user;Pwd=password;Port=3306;
-mstDatabaseConfiguration=default
-mstDatabaseAutoCloseConnection=true
-mstDatabaseLanguageType=MySql

The active bridge determines which values are required. Do not include production connection strings in client configuration.

Schema and Migration Rules

• Treat database schema changes as deployment changes.
• Back up production data before replacing a provider or model.
• Add explicit migrations for existing production data; changing a model does not migrate old rows.
• Keep timestamps in UTC when a DateTime represents an instant.
• Make purchase and other critical operations idempotent at the owning game-service layer.
• Test duplicate keys, reconnects, cancellation, and partial provider failure.

Provider details:

• LiteDB bridge
• MongoDB bridge
• SqlSugar bridge