Production ready?

[unkillbob]

Hey :) Loving the look of this library and keen to use it in production within the next couple of months, just noticed that its only 0.3 though. How stable is the current API? Do you have any plans to 1.0 anytime soon?

[alekseykulikov]

Hey, it's a good question. In general API is stable, and I'm willing to follow semver, but here's a few reasons why it's still 0.3:

• I need more feedback, I may miss something, that other developers find useful
• review db.use() for plugins API. I want to keep core minimal and stable, and allow to add advanced functionality through plugins.
• add schema.dropStore() and schema.dropIndex() for full cover of onupgradeneeded callback
• update documentation (need help), now it does not cover all cases and details
• maybe move plugins/treo-websql and plugins/treo-promise to separate repos

I'm currently using it in some projects, and going to actively develop and support this library. I guess a couple minor releases, and it will get 1.0 pretty soon.

[unkillbob]

Awesome! Thanks for the detailed response!

Awesome to hear that the API is pretty stable and we can expect a 1.0 soon! We're pretty keen to help in any way we can - point me in the right direction for the missing docs and I'll see if I can find some time to have a bash at it next week :).

As for feedback, here's our thoughts:

• love the nice clean simple API. Its great how the schema/db creation is all synchronous. The API is especially great when plugged with the promises/generators plugin.
• on that note, the plugin system is awesome and we'll definitely be making use of the promises plugin and quite possibly the websql fallback too. Its great to hear the intention to keep the core API minimal and stable - strongly agree with that approach.
• its also great that you permit access to the underlying native APIs (specifically cursors) so as not to prevent use cases your API doesn't cover

A couple of things we think could be improved on:

• a decent abstraction for iterating through objects in a store (i.e. an abstraction over cursors) would be great - however possibly something that can be provided via plugin (and something we're considering building ourselves)
• the ability to reuse the same transaction to write to multiple object stores. Not sure if this is already possible and just something that needs documenting?

Keep up the great work and let us (us being https://github.com/vend btw) know how we can help :).

[alekseykulikov]

Hi James, I’m so glad to see you interest and would be happy to take any help you provide.

I think this commit makes db.use() good enough. Also I’m wondering about schema API. Should it have put/del methods, how explicit it should be, what do you think?

the ability to reuse the same transaction

I see reasons to write in one transaction. db.transaction() has same semantic as original IndexedDB, so you can pass array of names. Check how store use it as example. However doing so, you miss store’s methods like put, del and batch, which uses one transaction and listen oncomplete to call cb. But it can’t be a problem, because most of sync processing happen in db instance. It might be a separate plugin. Let me know, how you see it.

a decent abstraction for iterating through objects in a store

Yes, this is a good point, I don’t like current store.cursor() API either, could you say how do you see this improved?

For documentation:

• I don't have examples for ranges
• also keyPath and autoIncrement does not covered well
• low level methods, especially store.cursor & db.transaction.

Thank you for support. P.S. Vend looks amazing!

[alekseykulikov]

Hi @unkillbob! How is it going?

I was thinking about syntax to reuse readwrite transaction for many stores (I don't see reasons to reuse readonly transaction so far):

db.write(['books', 'magazines'], function(books, magazines) {
  books.put('key1', 'value1');
  books.put('key2', 'value2');

  magazines.batch([
    { id: 'id1', title: 'Quarry Memories', publisher: 'Bob' },
    { id: 'id2', title: 'Water Buffaloes', publisher: 'Bob' },
    { id: 'id3', title: 'Bedrocky Nights', publisher: 'Tim' },
  ]);
}, function(err) {
  console.log(err || 'success');
});

thoughts? It might be integrated to core, together with some abstraction around cursors (node-streams come to mind, but it might be too heavy).

[unkillbob]

Hey @alekseykulikov!

Apologies for the delay in response, furiously trying to get my current project done and dusted so I can focus on the next one (that will make use of treo).

The updated db.use() API and the proposed db.write() API both look great to me! I think db.write seems pretty core too so reckon it should be part of the core API.

As for an iteration API, node-streams is pretty awesome and I think that'd suit our use cases just fine. I'd say iteration is a good candidate for a plugin though as a lot of people might not need it for simple use cases and there could potentially be a few different flavours with slightly different APIs - that's my thoughts on it at least.

I think the Schema API definitely needs deleteStore and deleteIndex methods. I can't think of a use case for put on the Schema API off the top of my head - do you have something in mind that might need it?

Thanks for the list of doc todos, hopefully I'll find some time next week to get stuck in and send a few pull requests - do you have contribution guidelines? Otherwise I assume a standard fork + pull request to master branch workflow.

[alekseykulikov]

Hey @unkillbob, thank you for thoughtful response! In weekend, or next week I will try to implement db.write, schema.dropStore, and schema.dropIndex and release 0.4.0. Completely agree about iteration, it should be a plugin. I will add better documentation for store.cursor as underlying methods for iteration kind of plugins. Maybe someone will implement it, for now my purposes are covered by existing methods.

do you have contribution guidelines?

I have no special contribution guide, fork + pr. For code patches follow my style for consistency :)

[unkillbob]

Closing this issue as we're happily using 0.3 in production already and keeping a close eye on 0.4. Hope to find some time to contribute more soon!

[alekseykulikov]

@unkillbob, it's great to hear!