Closed lwerdna closed 12 years ago
also, the schema needs to change to store per-game RD
currently for a game, we score the players and their ratings at the time of the game - I want also the RD at the time of the game to be stored also
Updating schema and game recording mechanics now.
Schema update done, working on import now.
Player.dat import working
games.dat updated syntax midstream...
notation changed from identifying point delta to identifying absolute rating
Importing working fine now. Games.dat is expected to follow syntax of the latest games (absolute rating shown instead of delta). Will have to update when .dat files are finalized.
ok, the new players.dat and games.dat are uploaded - you should be able to convert them now
don't be afraid to completely change it away from DbText
a good test of whether or not it works is to run:
$ ./admin.py seeddb
which will add some random players and play 1000 games .... then save off a copy and call it "GOOD"
now edit some of the scores in the database by hand (essentially corrupting some of the scores) and run:
$ ./admin.py recalculate
the database now should match what's in the "GOOD" copy ....
at this point, these steps exercise all of the gameplay interactions with the database
./admin.py seeddb works fine now with SQLite
./admin.py recalculate does not
Was not matching containers used in dumping games. Updated, now working 100%. Verified by...
./admin.py seeddb cp bugtrack.db bugtrack.db.good sqlitebrowser bugtrack.db ...much with ratings... sqlite3 bugtrack.db .dump > db sqlite3 bugtrack.db.good .dump > db.good diff db db.good ...notice diff... ./admin.py recalculate
Using SQLite is currently slower than raw text, but works 100% as far as I can tell. I vote to put this one to bed.
tested and tested - all code now uses DbSqlite and players.dat and games.dat have been rm'd on the server
The dbsqlite.py is in place, but it's not yet invoked ever... (currently we use DbText)
note: remember not to accidentally add or commit player data to the repo