Open MHHukiewitz opened 1 year ago
I started using v1 posts instead of v0 posts. I wonder why we did not earlier, as it seems a cleaner, albeit minimalistic, endpoint for getting posts. There should be no problem in changing back to v0 posts though.
A few points on my ToDo list:
DomainNode
: Should keep a synchronized cache with a subset of all Aleph messages.
confirmed
in the watch_messages stream, after some pre-defined timeout.BaseAlephClient
and BaseAuthenticatedAlephClient
pure interfaces.UserSessionSync
and AuthenticatedUserSessionSync
MessageCache
implement UserSessionSyncInterface
instead of BaseAlephClient
, as all provided methods can be sync.DomainNode.__enter__()
with a DomainNodeSync
class.Implemented all of the suggested changes by @odesenfans, highlights:
processed
, they are removed from the cache.Failed to retrieve llama text: ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response'))
Failed to retrieve llama text: ('Connection aborted.', RemoteDisconnected('Remote end closed connection without response'))
Context size not enough, I rate this PR manually as BLACK
This PR adds +1,937 and -16 lines of code to the project.
What is the impact of this PR on the test coverage ?
What is the impact of this PR on the test coverage ?
It actually improved relatively, as the new code has more coverage than the existing one.
Reopened with smaller scope from #31. Depends on #54.
Problem
Some apps require access to the same messages over and over again. This puts unnecessary strain on the CCN API and increases the latency of apps using Aleph Messages.
Solution
This pull request proposes a solution by introducing a message cache implemented with Peewee and an SQLite database in the Aleph SDK. The message cache effectively stores frequently accessed messages, eliminating the need for repetitive CCN API calls. With the message cache in place, apps utilizing the Aleph SDK will experience enhanced efficiency and responsiveness in accessing messages.