High Level Database Access: Difference between revisions

Content deleted Content added
imported>Hendrik Brummermann
No edit summary
imported>Hendrik Brummermann
No edit summary
Line 15:
== 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 complete [http://stendhal.game-host.org/hudson/job/marauroa_HEAD/javadoc/marauroa/server/game/db DAO package]. Note that games can add their own DAOs.
 
So lets assume you want to log a gameEvent about a player logging out:
Line 21:
gameEventDAO.addGameEvent(playerName, "logout");
</source>
 
Games are able to subclass DAO objects in order to add or replace their own functionality. This, however, means that we cannot simple create a new GameEventDAO ourselves. Instead we have to use the DAORegister:
 
<source lang="java">
GameEventDAO gameEventDAO = DAORegister.get().get(GameEventDAO.class);
gameEventDAO.addGameEvent(playerName, "logout");
</source>
 
Now games can register their own subclass instead of GameEventDAO.class and we use it automatically.
 
== Transactions ==
 
TheseAll classespublic replacemethods thein oldDAO IDatabase / JDBCDatabase and do the database stuff. All of their methodsclasses 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: theThe 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.▼
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...
 
<source lang="java">
DBTransaction transaction = TransactionPool.get().beginWork();
try {
DAORegister.get().get(GameEventDAO.class).addGameEvent(playerName, "saved");
DAORegister.get().get(GameEventDAO.class).addGameEvent(playerName, "logout");
} finally {
TransactionPool.get().commit(transaction);
}
</source>
 
Please note that commit() will automatically perform a rollback and throw an SQLException if there are any errors.
▲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.