| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
| |
This was done with the old design in mind, but with the query
thread offloading, returning false is meant to signal a failure
in completing it. A connection lost with PostgreSQL or BUSY error
with SQLite, for example.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The monotonic uptime was used exclusively with caches and having
a resolution of SECONDS allows it to be stored as an int without
risk of wrapping (~68 years). Using MILLISECONDS meant that it
would wrap after ~25 days which is totally possible and EXPECTED.
Just as an example, the small test server I ran for about 1 month
had ZERO downtime on the QueryManager except for when I manually
restarted it. It was probably very close to wrapping when I took
it down.
|
| | |
|
| |
|
|
|
| |
This also avoids conflicts with database RESULT objects that we lacked
with SQLite but show up with PostgreSQL and MySQL.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
With this change the game server is able to login again but we
still need to re-implement/re-fit the other queries for it to
properly startup.
|
| | |
|
| |
|
|
|
|
| |
This moves queries from `src/connections.cc` to `src/query.cc` and
adds a few missing details. The only thing left is to review query
processing and tie database operations to the `TDatabase` struct.
|
| |
|
