You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It may be interesting to offer the user the choice 2 implementations: atom-based and agent-based (currently there's only atom-based).
Potential benefits:
In the atom-based implementation, when the .transact() or .transactAsync() method returns, the transaction has systematically been committed, meaning that any subsequent call to .db() will reflect the transaction. We don't want users to erroneously rely on this in dev and have bad surprises in production. We could even go further expose an option to emulate latency.
more generally an Agent seems closer to the execution model of a real transactor (transactions are queued and executed asynchronously)
under some circumstances, this may increase the speed of tests by relieving the main thread of transaction work.
The text was updated successfully, but these errors were encountered:
I've added a PR that implements the mock connection with an agent.
I don't think the user should choose, and that only the agent based implementation should be available, as its closer to the 'real' implementation
It may be interesting to offer the user the choice 2 implementations: atom-based and agent-based (currently there's only atom-based).
Potential benefits:
.transact()
or.transactAsync()
method returns, the transaction has systematically been committed, meaning that any subsequent call to.db()
will reflect the transaction. We don't want users to erroneously rely on this in dev and have bad surprises in production. We could even go further expose an option to emulate latency.The text was updated successfully, but these errors were encountered: