Persistent memory backend? Load/dump fixtures?

[leplatrem]

Our use case is the following: for kinto-http.js we want an integration test to reproduce the situation where the history plugin was enabled after the creation of the collection. Since we use the memory backend, there is no persistence of data after change of configuration. (See https://github.com/Kinto/kinto-http.js/pull/173)

We have several strategies there:

• Mock server responses — but then it's not an integration test anymore
• Use a persistent backend like Redis or PostgreSQL — but then every contributor to kinto-http will have to run this backend for running the tests
• Add a way to load and dump data at the database level to maintain the incomplete history — ie. not like kinto-wizard
• Make the memory backend persistent — ie. write a file on every write operation and load it if present on startup

My favorite one would be the last one, since we already have synchronized calls on the write method of memory. And memory is a toy anyway...

Thoughts?

[Natim]

What about the idea of removing the memory backend and using a SQLite3 backend (we can use a temporary file in memory to keep the memory backend feature) plus we gain transaction for free? #754

[leplatrem]

I agree, this would be the cleanest strategy.

However the dump/load idea can be implemented in less than 50 lines, whereas the sqlite requires a lot more efforts (sql queries, migrations, ...)

[glasserc]

If we change the memory backend to write to a file and read it on startup, we ought to rename it.

Of the non-SQLite solutions, I think dumping/loading directly into the memory backend is the cleanest.