Attack Objectives. I’ve had a number of requests to expose which towns are currently under an objective – both from Ramp for CS&R and from people interested in pulling that data from Wiretap.
Unfortunately, this data is not exposed to the database by the server responsible for tracking AO assignments (the strat host).
The only thing keeping me from simply throwing in a column or a table for AOs is closure: ensuring that a server-outage doesn’t leave an open-looking AO entry in a table.
Solutions I have aplenty:
- Keep the ‘closed’ field on all open AOs set to 150 seconds in the future and update the field every 60s. Con: heavy handed database pounding.
- Wrap the server process with a script that automatically closes all active AOs in the database. Con: The server may be down due to a database outage.
- Force the server to close all outstanding AOs on restart. Con: Long periods of incorrect data when the server is down for maintenance/patches.
But I don’t really have time right now to sit down and think through the various use-cases I have and work out the best strategy given our architecture. If we were using Postgres or Oracle at the moment, I know what I’d do.
But we’re using MySQL 4.1 and the technologies like views and PL/SQL aren’t mature enough in any version of MySQL for me to be comfortable about moving to them. We’ve been experimenting with Trac in-house, which uses Postgres. Mmm. Boy did it feel good to be type be in pgsql typing commands. I’ll argue the case for MySQL for WWII Online on technical grounds, but that doesn’t mean I don’t feel unclean for then being a MySQL user :)