Closed fluffyemily closed 6 years ago
TxObserverService called when InProgress commits and filters TxObservers that are affected by the tx's that occurred and notifies them of what changed
So if I do this:
it sounds like my observer will be notified of a write that occurred prior to registering, no? Is that what we want? I'm not sure what the user expectation would be.
But surely, until that write commits, it's sorta not done?
Originally I batched up transacts inside the observer, logging them against each matching observer as they occur and then only sending the batches on commit. It would be easy enough to revert back to that strategy and would solve this problem.
Or keep the map of observers->transacts inside InProgress
by making observers_for_attributes
a public function. Either way it would work.
Or keep the map of observers->transacts inside InProgress by making observers_for_attributes a public function. Either way it would work.
IMO:
InProgress
.Conn
.InProgress
.
Transaction observation
TxObserverService
inConn
that takesTxObserver
s and registers them against keys and for sets of attributes.InProgress
batches up tx's as it goes along so granular notification can be provided.TxObserverService
called whenInProgress
commits and filtersTxObserver
s that are affected by the tx's that occurred and notifies them of what changed.Things I could still do:
TxObserver
entirely and just register functions against keys insideTxObserverService
.Things I tried for storing observers:
Trait Objects -- Store trait object as reference - caused lifetime issues when attaching
tx_observer_service
to anInProgress
as the lifetime for the trait object reference couldn't be worked out. -- Store trait object insideRefCell
inside anRc
- got mutability but required definition of var asRc<RefCell<Trait>>
which caused sizing issues - basically you can't specify a trait object as a generic parameter. To resolve this would mean making a concrete type implementing trait and storing that, which kinda defeats the purpose. -- Store trait object insideBox
- this works but means that the observer service owns the observer which kinda defeats the point.Functions -- Pretty much everything written above but using functions rather than trait objects
Futures -- Experimented with returning a Future on observer registration, but I had problems in 2 ways: --- Difficulty telling the future that it has completed without turning the entire observer service into a Future. --- Once the future has completed, consumers needed to reregister in order to get another future, which was clumsy. --- It's possible I didn't understand the
Futures
orStreams
documentation properly and there is still a way to do this.