Currently we have a generic fmke_kv_driver module that handles all implementations of the simple interface database drivers.
It turns out that some of the logic in fmke_kv_driver assumes that the data model uses nested objects, and we're not able to write a driver using this module that uses a non-nested data layout.
In fact, the fmke_kv_driver adapter is a special module. If we allow it to make assumptions on the data model, it should be clearly labelled as such. We could have a fmke_adapter_normalized that assumes a normalized data model, and for each database uses different techniques to store and fetch data optimally. If we keep a minimalistic interface (theoretically only get/1, put/2) on the drivers, we can make multiple such adapters, each making their own assumptions and using different techniques to store and retrieve the data.
Currently we have a generic
fmke_kv_drivermodule that handles all implementations of the simple interface database drivers. It turns out that some of the logic infmke_kv_driverassumes that the data model uses nested objects, and we're not able to write a driver using this module that uses a non-nested data layout.In fact, the
fmke_kv_driveradapter is a special module. If we allow it to make assumptions on the data model, it should be clearly labelled as such. We could have a fmke_adapter_normalized that assumes a normalized data model, and for each database uses different techniques to store and fetch data optimally. If we keep a minimalistic interface (theoretically onlyget/1,put/2) on the drivers, we can make multiple such adapters, each making their own assumptions and using different techniques to store and retrieve the data.