Add Storage interface to connect to storage backends?

[pwalsh]

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.

• https://github.com/frictionlessdata/jsontableschema-py/blob/master/jsontableschema/storage.py
• https://github.com/frictionlessdata/jsontableschema-bigquery-py/blob/master/jsontableschema_bigquery/storage.py
• https://github.com/frictionlessdata/jsontableschema-sql-py/blob/master/jsontableschema_sql/storage.py

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

• Implement the basics of the Storage class
• Implement a JSON storage backend
  • An object
  • The "name" of the table is the name of the resource, and a table is an array
• Tests

{
  "table_name": [
    { ...row ... },
    { ... row ... },
    etc.
  ]
}

@roll any comments? If you dont like the idea of a default JSON backend LMK.

[roll]

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.

[roll]

@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:

• we have a core python stack: tabulator, jts+storages, dp, goodtables
• we will be having js,ruby,java,r etc ports: basic jts, dp

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.

[pwalsh]

@roll it was already done. @zhenyab used this to build the models. we are just waiting on his PR :)

[roll]

It's going on here - frictionlessdata/tableschema-models-js#1