Roadmap for v2

[PhilWaldmann]

It has been a while since the last major update of openrecord. The reason is, it's running in production for for almost 3 years without problems. And is has all the features that we needed.

openrecord was originally written for node 0.10 and a lot has changed in the javascript world since then.

Things I like to change/add for version 2.0 (v2 branch):

• [ ] ~Use ES6 import/export~ use babel...
• [x] async/await support
• [ ] ~Add support for NoSQL stores (e.g. DynamoDB)~ => V2.1
• [ ] ~Better support for transforming result data~ => V2.1
• [x] more declarative model definition syntax
• [ ] ~Browser support #28. e.g. with a thin wrapper over rxdb and the rest-store, combined with cross store relations.~ https://github.com/PhilWaldmann/openrecord/issues/28#issuecomment-372953160
• [x] Graphql support
• [x] Real docs!!
• [x] ESLint (instead of jshint)
• [x] remove async in favor of promises (https://github.com/PhilWaldmann/openrecord/issues/36#issuecomment-318508873)
• [x] Oracle support (#53)
• [ ] ~Cordova SQLite native support~ (https://github.com/PhilWaldmann/openrecord/issues/28#issuecomment-318719391) https://github.com/tgriesser/knex/issues/1845

[mnort9]

ES6 classes for model definitions would be great 👍

[SampsonCrowley]

What I'd really like to see added to this list would be extensible models like ActiveRecord.

It would be extremely helpful to set an model template that all other models inherit from, like application record in rails. any methods or configurations present in that model would then usable by the entire application

[PhilWaldmann]

@SampsonCrowley This is already possible!! But it's not documented yet...

you could use this.require('some/path/to/*-include.js') in your model definition function. Take a look at the following test file. It's a way to split your model definition into multiple files.

There is also the this.include() method, but there are currently no tests. However, this method allows you to add plugins (same as the global plugins config variable) to a specific model only.

And you could even use specific plugins/shared definitions on a temporary basis (see temporary definitions

[SampsonCrowley]

that would do just fine!

[SampsonCrowley]

I'd like to add lazy loaded associations to this for times when you start off needing just the parent model, but execution branches may lead to needing to load children into the record.

could be done with getters and setters to make the code execute syncronously

[PhilWaldmann]

@SampsonCrowley I'm not quiet sure what you mean. Loading data from a datastore is always asynchronously.

[SampsonCrowley]

@PhilWaldmann

Loading from the datastore is asynchronous but there are ways to make async code execute synchronously, that way you could access the associations the same way whether they were preloaded or lazy loaded. I was just throwing that part out there.

Or you could go the other direction and make all associations promise based, even if they are preloaded (instant resolve)

the important part I would like to see added to the road map is a way to lazy load all associations

[PhilWaldmann]

Got you! Thx

[PhilWaldmann]

version 2.0 released