search

vvvvalvalval / datomock

Mocking and forking Datomic Peer connections in-memory.
MIT License
130 stars 6 forks source link

Agent-based implementation #2

Open vvvvalvalval opened 8 years ago

vvvvalvalval commented 8 years ago

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 commented 6 years ago

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