Closed pwalsh closed 7 years ago
I think there should be a separation between interface to implement (though for languages like python and js it's more like a documentation than real implementation check) and concrete implementations. So jsontableschema.storage.Storage
is an interface (sounds better than stub=) but core libs also could provide any builtin concrete implementations like JsonStorage
, FilesystemStorage
(etc) But in docs better to tell people implement interface than subclass concrete drivers.
I thought more about builtin FilesystemStorage
because it could encapsulate all filesystem interaction internally used by library. So it could be not just an example. But I haven't really dove into this idea for now.
@pwalsh
Now we have jsontableschema-models-js
covering similar concepts. So question - do we need jsontableschema.Storage
for js at all?
As I could see it:
If we not going to write sql, bigquery etc drivers for javascript this javascript.Storage
just not needed (it's not a part of base specs implementation). Not introducing storage concept here we could reduce maintenance cost a lot. Because sql etc integrations could be a really big work here - so needed a strong reasons to start it.
My preference to do first basic jts, dp implementations for js when we'll be having resources for it.
@roll it was already done. @zhenyab used this to build the models. we are just waiting on his PR :)
It's going on here - https://github.com/frictionlessdata/jsontableschema-models-js/issues/1
Description
Requires #22
In the Python lib, we have the concept of a Storage interface, which is used for push data from a table of data in JTS to a backend, and vice versa. The base class
jsontableschema.storage.Storage
, in Python, currently just stubs out the core API, and then we have two plugins that implement this API for BigQuery and SQL.We want to implement the base
Storage
class in the js lib, but not simply as a stub of the API, but with a minimal example of JSON/Object storage.Tasks
Storage
class@roll any comments? If you dont like the idea of a default JSON backend LMK.