High Level Database Access

• General Information
  • Overview
  • What is Marauroa?
  • Features
  • Glossary
  • Differences
  • History
  • New in Marauroa 3.8
  • New in Marauroa 3.9
• Using Marauroa
  • Building
  • Initial Steps
  • Tutorial
  • Core API
  • Adventure Games Concepts
  • Database Access
  • server.ini
  • Testserver
• Internals
  • Network Design
  • Role Playing Design
  • Database Design
  • Database Access
  • Eclipse
  • Roadmap
  • JUnit

Database

Marauroa

• High Level Database Access
• Low Level Database Access
• Marauroa Database Structure

Stendhal

• Stendhal Database Structure

This article describes how you can use Marauroa in your games to accesses the database on a high level. The internal works are explained in Low Level Database Access. The table structure of the Marauroa database is explained in Marauroa Database Structure.

Most of the database access is transparent. For example if client requests the creation of an account and the game server logic accepts that request, Marauroa will automatically add the necessary rows to the database.

But in some situations it may be necessary for you do database operations. For example you may want to log gameEvents or you might have a website allowing account creation.

Data Access Objects

In compliance to the Marauroa architecture, database access related code is not spread all over the code base but concentrated in a set of data access objects (DAO). There is JavaDoc available for the DAO package.

So lets assume you want to log a gameEvent about a player logging out: <source lang="java"> gameEventDAO.addGameEvent(playerName, "logout"); </source>

Transactions

DAO stands for "data access object". The basic idea is, and has been from the start, that the database related code is not in the original classes but at some central point outside the game logic. This used to be JDBCDatabase, but one single class for all database operations is very hard to maintain. So JDBCDatabase has been split into a number of small classes focused on one area each: AccountDAO, CharacterDAO, GameEventDAO...

These classes replace the old IDatabase / JDBCDatabase and do the database stuff. All of their methods have two signatures: One with a DBTransaction object as first parameter and one without. This is for your convenience: In most cases those functions are not part of a larger context so you do not have to care about transactions at all: the DAO-classes do the transaction handling on their own. There are, however, a small number of cases in which you want to do multiple calls to DAOs in one single transaction. In this case you get a DBTransaction from the TransactionPool and provide it as first parameter to DAO-methods. After you are done you must either commit or rollback your changes with the appropriate methods in the class TransactionPool.