ajanata
commented
10 years ago This one is going to require some more thought for how to make it work with where I want to take user accounts and user-submitted cards, which could cause cards to be added, removed, or changed at nearly any time. I will try to actually spec out my plans this weekend and we can see how this could work with that.
As discussed on de65ad2, this loads the card sets from the database once at startup, and then never again unless manually requested by the admin. In particular it avoids hitting the database on user login and game start, which was previous behaviour. (This was prompted by database load performance issues when users logged in, while trying to run a server on RPi.)
Note that the database-editing pages still operate directly on the database, as before. Changes made using these pages will not be visible to users until the server restarts or the admin explicitly reloads the cards. (And then, as before, new cards are available immediately but new sets require players to relog.)
I've only used this in a single-server setup (where the server is frequently restarted), so from my perspective this is all pros and no cons. Given that you have multiple servers sharing one database, you might find it slightly more annoying to update cards (you'll have to reload on each game server), but it probably wouldn't be hard to add some kind of smarter multi-server synchronisation if it becomes too much of an issue.
This branch is based on current master, to make it easier to merge this or #101 in either order; but there will be some minor (and obvious) conflicts with that PR. If you don't want to resolve the conflicts yourself, just pull one or the other and I'll fix up the other one accordingly.