It is possible to reduce to a value that is not a dict in "insert_item()"
and "update_item()". Raise a ServerError with a clear description of
what went wrong in these situations.
Signed-off-by: Eric Callahan <arksine.code@gmail.com>
It is possible that Moonraker can be instantiated while the eventloop
is running during tests. To avoid errors allow synchronous calls until
the server starts.
Signed-off-by: Eric Callahan <arksine.code@gmail.com>
Since the User DB is not going to be large cache the users
in local memory and sync with the DB when changes are
made to the local user store.
Signed-off-by: Eric Callahan <arksine.code@gmail.com>
Now that all transactions run in a thread it is possible for them to
interleave. The record based operations allow for batch operations
within a single transaction.
Signed-off-by: Eric Callahan <arksine.code@gmail.com>
Wrap command implementations in with a _run_command() method. All
database commands now return a Future object. If the command was
run before the eventloop starts its possible to immediately query
the Future's result.
Signed-off-by: Eric Callahan <arksine.code@gmail.com>
Similar to the update method, however sync will remove any
keys in the database not in the new value.
Signed-off-by: Eric Callahan <arksine.code@gmail.com>
Rather than creating two wrappers, use a single wrapper whose methods
always return a future or awaitable. If the operation occurs during
the __init__() method of a component it will be syncrhonous, and the
result from the future can be immediately queried.
Signed-off-by: Eric Callahan <arksine.code@gmail.com>
Rather than reading out the entire database, attempt to pop off
empty keys in each database. This should should speed up
init on platforms with slow disk I/O and prevents reading
large namespaces in memory.
Signed-off-by: Eric Callahan <arksine.code@gmail.com>
It isn't necessary to read out the entire namespace, just attempt
to fetch the record and reduce the key list.
Signed-off-by: Eric Callahan <arksine.code@gmail.com>
Since transactions are now threaded we need updating
and clearing a namespace needs to be performed within
one transaction.
Signed-off-by: Eric Callahan <arksine.code@gmail.com>
Database transactions can perform disk I/O tasks, which at times will
block the eventloop. Run all transactions in threads to prevent this
from occuring.
Signed-off-by: Eric Callahan <arksine.code@gmail.com>
Move the KlippyConnection class into its own module. Refactor
init to use loops rather than callbacks, this reduces complexity
of tracking and cancelling callback handles.
All Klippy state previously tracked by the Server is now in the
KlippyConnection. This improves testing and makes the code
less ambiguous, ie: the `server.make_request()` method is not
as clear as `klippy.request()`.
Signed-off-by: Eric Callahan <arksine.code@gmail.com>
The result should be a dictionary of dictionaries rather than a
dictionary of SectionProxy objects.
Signed-off-by: Eric Callahan <arksine.code@gmail.com>
Commit 7401192 introduced a regression where the saved klipper
paths were not loaded into the Update object.
Signed-off-by: Eric Callahan <arksine.code@gmail.com>
Shallow clones don't report the tag in git describe, so use
git rev-list to extract the tag and prepend it to the version
string.
Signed-off-by: Eric Callahan <arksine.code@gmail.com>
If Klipper or its python executable is located at a custom path
this allows moonraker to instantiate its update on startup
rather than wait for Klipper to connect. This also resolves an
issue where Klipper's update state is always refreshed on startup
when its located in a non-default path.
Signed-off-by: Eric Callahan <arksine.code@gmail.com>
When the "none" provider is set service action APIs will be disabled
and return an error when called. Service state tracking is also
disabled.
Signed-off-by: Eric Callahan <arksine.code@gmail.com>
All requests to update, refresh, recover, or reinstall must acquire
the command lock. Given that the individual Deployment implementations
are not (and should not be) called from outside of a request the locks they
use to prevent unwanted re-entry are redundant, confusing, and could
potential result in a deadlock if used improperly.
Signed-off-by: Eric Callahan <arksine.code@gmail.com>
