[WIP] changes Feature/storage

[zhenyab]

@roll @pwalsh Please, comment

[coveralls]

Coverage decreased (-24.2%) to 59.922% when pulling 2ac4914 on feature/storage into 6ba900b on master.

[pwalsh]

@zhenyab can you just link me to the specific files to review here? I tried to do this by looking at different commits, but there is so much noise that it is hard for me, as a reviewer, to identify the actual application code, and seperate it from the files you added as dependencies.

[pwalsh]

@zhenyab why is this committed? it looks like transpiled files from babel, right?

[zhenyab]

@pwalsh I need to use jsontableschema, but can't use ES6 version in the project, while it is run on NodeJS 4.x. I did automatic cloning of repository and building the scripts, but found that it would be better just to add it to the code base of the project.

[zhenyab]

Files you are interested in:
app/storage/*
app/models/*
app/services/cases.js
app/services/trials.js

[pwalsh]

@zhenyab ok, this looks really good. Does it simplify the application code in useful ways?

What I don't see is a query method to filter a "table" - probably because you dont need it here but I'd expect we need it in general as part of the lib. WDYT?

Can you do these things now:

1. Do a PR on the core lib just fpr the storage
2. Finalise Release jsontableschema-v0.2 frictionlessdata/tableschema-js#36 (sync with @roll )
3. Do a PR with the model-specific code on https://github.com/frictionlessdata/jsontableschema-models-js

[zhenyab]

@pwalsh Yes, introduction only jsontableschema simplified the code significantly. Models also looks useful, while it is kind of ORM, and work with ORM is more comfortable. In case of "tracker ebola" it possible probably to completely remove services.

Yes, I did not provide some query methods, because in this project no need in it. Tracker ebola has very simple data model.

Another thing, need to port all the models into ES6, because in current version some code does not look elegant, especially inheritance of methods and cloning the existent model.

Other issues, yes, I can do, of course.

[pwalsh]

@zhenyab

• so great, do that, and do it as ES6 in the models codebase, for that PR.

The other thing - I'd like to probably seperate load from the query methods. like, for example, have an option to load on app startup, and then have a default of load=false when contructing a model (assumes that data is loaded), and ability to force load on construction, with load=true. Does that make sense?

Lastly @zhenyab we'll leave this PR open now, but we'll continue discussion over on the jts and the models repos.

thanks!