| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
| |
* refactor server to allow pluggable db and tracing
* clean up
* fix descriptions
* remove dependencies
|
| |
|
|
|
|
|
| |
* Allow server configured page size
* Backwards compat via semver checks
* Correct header name
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Added DELETE register endpoint
* Added remove function to database
* Added unregister to client
* Updated docs
* Renamed functions
* Reformatting
* Used execute instead of fetch in delete_user
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
* Drop events. I'd still like to do them, but differently
* Start adding delete api stuff
* Set mailmap
* Delete delete delete
* Fix tests
* Make clippy happy
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
* Add configurable history length
This allows servers to decide the max length of each history item they
want to store! Some users might have much larger history lines than
others.
This setting can be set to 0 to allow for unlimited history length. This
is not recommended for a public server install, but for a private one it
can work nicely.
* Format lol
|
| |
|
|
|
|
|
| |
* ignore JB IDEs
* tidy-up imports
* add rustfmt config
|
| |
|
| |
And also correct a typo
|
| |
|
|
|
| |
It's not ideal as we should be explicit about what is being queried!
A part one for sorting this all out :)
|
| |
|
|
|
|
|
| |
* enable tracing on server
* fmt
* instrument handlers
|
| |
|
|
|
|
|
|
| |
I just deployed the older version and it was falling back on the full
count. Turns out this is because it won't upcast from INT4 to INT8
automatically, and it has to be manual
At some point the underlying total should be changed to int8, but also I
highly doubt anyone will have enough shell history to fill an int4 lol
|
| |
|
|
|
|
|
|
|
|
|
| |
* Use the count cache
By default read from the count cache - if there is no value there, then
do a full COUNT. The cache will be filled when the user posts up some
more history
* clean up server db error handling
Co-authored-by: Conrad Ludgate <conrad.ludgate@truelayer.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
This can be used in the future for sync so that we can be more
intelligent with what we're doing, and only sync up what's needed
I'd like to eventually replace this with something more like a merkle
tree, hence the hash field I've exposed, but that can come later
Although this does include a much larger number of count queries, it
should also be significantly more cache-able. I'll follow up with that
later, and also follow up with using this for sync :)
|
| |
|
|
|
| |
* make everything a cow
* fmt + clippy
|
| |
|
|
|
|
|
|
|
| |
* Begin moving to sqlx for local too
* Stupid scanners should just have a nice cup of tea
Random internet shit searching for /.env or whatever
* Remove diesel and rusqlite fully
|
|
|
* Switch to Cargo workspaces
Breaking things into "client", "server" and "common" makes managing the
codebase much easier!
client - anything running on a user's machine for adding history
server - handles storing/syncing history and running a HTTP server
common - request/response API definitions, common utils, etc
* Update dockerfile
|
