This issue tracks reimplementing the work from stale PR #3244, which has been closed because it is too far out of date to merge directly.
Original pull request
What the original PR was trying to do
Description of Changes These changes allow SDK consumers to register a tokio::sync::mpsc::UnboundedSender for a DbConnection that directly receives all database updates instead of the ClientCache. Rationale For writing tooling the current client cache feels very inefficient - these changes allowed us to reduce memory consumption by around a factor of 8, from being able to run the tooling for one region of BitCraft Online to all of them. Batch processing all rows in a database update as well as processing them in a different thread also lead to increased performance. Expected complexity level and risk 1 - for complexity i believe this is a fairly minor change, although not completely aware of your scale. ? - for risk. Behavioral changes only exist if the channel is registered via DbConnectionBuilder::with_update_channel, currently hidden from the docs. Risk may increase signi...
Closure context
- I'm going to close this PR since we would really need to provide this as a distinct feature in all of our SDKs. I will create a ticket to track that.
Reimplementation notes
- Reimplement this work on top of current
master in a new PR.
- Keep the original PR linked as historical context and as a source of useful implementation ideas where still relevant.
This issue tracks reimplementing the work from stale PR #3244, which has been closed because it is too far out of date to merge directly.
Original pull request
What the original PR was trying to do
Description of Changes These changes allow SDK consumers to register a tokio::sync::mpsc::UnboundedSender for a DbConnection that directly receives all database updates instead of the ClientCache. Rationale For writing tooling the current client cache feels very inefficient - these changes allowed us to reduce memory consumption by around a factor of 8, from being able to run the tooling for one region of BitCraft Online to all of them. Batch processing all rows in a database update as well as processing them in a different thread also lead to increased performance. Expected complexity level and risk 1 - for complexity i believe this is a fairly minor change, although not completely aware of your scale. ? - for risk. Behavioral changes only exist if the channel is registered via DbConnectionBuilder::with_update_channel, currently hidden from the docs. Risk may increase signi...
Closure context
Reimplementation notes
masterin a new PR.