One problem I've had while working with Dgraph, is that Dgraph does not have a test sandbox like Ecto has for Postgres. Since Dgraph does not offer multiple databases in a single instance, I'm wondering how other developers are solving this problem.
To illustrate, when running tests: The test may create new data and fetch old data:
- First run: Create node with
external_id: "1", returns uid: 0x1, external_id: "1"
- First run: Fetch node with
external_id: "1", returns uid: 0x1, external_id: "1"
- Second run: Create node with
external_id: "1", returns uid: 0x2, external_id: "1"
- Second run: Fetch node with
external_id: "1", returns nodes with uid: 0x1, external_id: "1" and uid: 0x2, external_id: "1"
A workaround I that use, is to add first: 1 and sometimes orderasc: created_on to queries. This works, and makes tests pass using the new data; but adding code simply to make tests work is obviously bad practice.
How are others solving this?
One problem I've had while working with Dgraph, is that Dgraph does not have a test
sandboxlike Ecto has for Postgres. Since Dgraph does not offer multiple databases in a single instance, I'm wondering how other developers are solving this problem.To illustrate, when running tests: The test may create new data and fetch old data:
external_id: "1", returnsuid: 0x1, external_id: "1"external_id: "1", returnsuid: 0x1, external_id: "1"external_id: "1", returnsuid: 0x2, external_id: "1"external_id: "1", returns nodes withuid: 0x1, external_id: "1"anduid: 0x2, external_id: "1"A workaround I that use, is to add
first: 1and sometimesorderasc: created_onto queries. This works, and makes tests pass using the new data; but adding code simply to make tests work is obviously bad practice.How are others solving this?