Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Agent-based implementation #2

Open
vvvvalvalval opened this issue Feb 21, 2016 · 1 comment
Open

Agent-based implementation #2

vvvvalvalval opened this issue Feb 21, 2016 · 1 comment

Comments

@vvvvalvalval
Copy link
Owner

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:

  1. 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.
  2. more generally an Agent seems closer to the execution model of a real transactor (transactions are queued and executed asynchronously)
  3. under some circumstances, this may increase the speed of tests by relieving the main thread of transaction work.
@ChrisBlom
Copy link

ChrisBlom commented Nov 30, 2017

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants