continuous-integration/drone/push Build is passingDetails
Adds new db tree for simple global state values (which also lays
foundation for other stuff), and stores device ID in that tree after
first login. The ID is then reused on subsequent runs of the
application.
This is simpler than storing device ID in config file.
Fixes#9.
Adds a new function `should_process` to rooms impl that determines if
calling could should proceed with processing an event ID. Event IDs
are recorded (along with room ID) as a key pointing to the
system-local timestamp of when the event was received. If the key was
not originally present, we instruct calling code to process the event.
Events are also asychronously recorded by timestamp using a sled event
watcher that listens to inserts in the main tree (described above).
This secondary tree will allow easy cleanup of old events in the
future.
The database API for user variables has changed somewhat again, this
time closer to the proper vision. There are now two separate sled
Trees in the Variables struct, one for user-defined variables, and one
for counts. Keys have been changed to be username-first, then room ID.
The signatures of the functions now also use a strongly-typed struct,
UserAndRoom.
As part of this, the Context object now once again avoids allocating
new strings.
Other random changes included here:
- Remove tempfile crate in favor of sled temporary db config.
- Add bincode crate in anticipation of future (de)serializing.
This is a bit of a large commit that adds basic database migration
support. It also alters the way user variables are stored in a way
requiring manual migration of existing data. The first automated
migration adds variable count in a new place.
This commit introduces the Sled embedded key-value store for keeping
track of user variables on a per-room basis. Extensive changes were
made to the command module to separate concerns and also pass the
database "connection" down the line.
- A new "Context" object was created to hold information and state
needed for command execution (namely the database).
- Database is very simple for now, storing only user variables.
Refactoring later for storing more complicated types.
- State actor moved into Actors struct, in preparation for either
more actors, or ripping the whole thing out entirely.
- Other modules are also more properly separated, notably
the config module is entirely self-contained.
projectmoon