Player serialization from-and to SQL database #496
Conversation
…gainst an actual database
… create_appearance and create_player
…ost, port, database name and driver
…t_items, get_attributes
…able, add get_account function
…matching, update serializer to not fire events
garyttierney
requested review from
Major- and
garyttierney
and removed request for
Major-
database/Dockerfile
Outdated
| FROM postgres:11-alpine | ||
|
|
||
| # And then copy over the apollo.sql script into the container's entrypoint | ||
| COPY apollo.sql /docker-entrypoint-initdb.d/init.sql |
There was a problem hiding this comment.
I don't want to start publishing custom PostgreSQL Docker images unless we need to compile native extensions. Instead of using the containers init scripts functionality we should be using something like Flyway to run migrations on the configured database.
game/src/main/java/org/apollo/game/database/ConnectionConfig.java
Outdated
Show resolved
Hide resolved
| } | ||
| } | ||
|
|
||
| private void putRank(Connection connection, Email email, PrivilegeLevel rank) throws SQLException { |
There was a problem hiding this comment.
I don't like the amount of manual interaction with PreparedStatements and data mapping we have to do in here. I'd prefer if we used something like Spring's JDBCTemplate or jOOQ to handle splitting out the data mapping code (into spring RowMappers or jOOQ Converters), common JDBC errors, and replace positional parameters with named parameters.
| * The associated queries that are ran by this serializer. | ||
| */ | ||
| private static final String | ||
| GET_ACCOUNT_QUERY = "SELECT password_hash, rank FROM get_account(?::text)", |
There was a problem hiding this comment.
Why are these queries implemented as functions?
There was a problem hiding this comment.
Because majority of them are slightly more complex than the usual one liners involving joins and such. Java doesn't support text blocks until 13 and we're on 11 now so that'd get a bit messy. Do you have a better idea?
There was a problem hiding this comment.
If the only reason is to cut down on the size of string literals than we can store the queries in a kotlin file (which does support multi-line raw literals). The game module already has the Kotlin compiler enabled so this won't be an issue.
database/apollo.sql
Outdated
| @@ -0,0 +1,506 @@ | |||
| CREATE EXTENSION citext; | |||
There was a problem hiding this comment.
Once we've got this schema into something that can manage it (i.e. Flyway) lets break it down and separate out schema primitives (like types and tables) from functions (whose migrations can be run repeatedly without the need to create new versions every time you update the function).
Solving #175