Note that for the onerror test with a bad version (too low), Firefox does not recover. Even if we wrap the open() in a try-catch block, Firefox throws an uncatchable error for such VersionError errors.

I think therefore, the only way we could work around this would be to always open the current version, reflect on what that version is, close the connection, and then either open the connection if the user-supplied version is good, or immediately reject if it is bad. I don't think it is worth doing this though, just to workaround a bug in Firefox. (I haven't reported the issue yet, however.)

PhantomJS 2.0 supports indexedDB (from my initial reading). I'd like to see how the tests run in PhantomJS and whether that can be used for CI instead of SauceLabs.

At the first database create, right after that, Google Chrome for Windows does not allow the call

server.people.add( {
    firstName: 'Aaron',
    lastName: 'Powell',
    answer: 42
} ).done( function ( item ) {
    console.log("Item 1 stored");
} );

The error message is : Cannot call method 'add' of undefined After creating the database, after a page Reload (opening an already created database) the above constructions works just fine ! Firefox works fine allowing that type of call even for the first time!

The sollution I've found is:

server.add( 'people', {
    firstName: 'Aaron',
    lastName: 'Powell',
    answer: 42
} ).done( function ( item ) {
    console.log("Item 1 stored");
} );

Should I do something special on first database creation on Chrome?

Change to prototype-based methods internally (to reduce functions added into memory); refactor Query to have succincter syntax (via createReturnObject).

Note that I have not committed dist as it could cause problems upon merges. You can just build dist when doing tests or what not and commit it yourself when you finish a merge or merges. I think this tends to be the most common practice anyways.

I like the idea of db.js – a simple promises-based API that transparently wraps the IndexedDB API (some other libraries have a bit too much magic behind the scenes for me to be comfortable). I really like the “modify” syntax for updating objects too. There are a few minor features I want to recommend adding… but that is for another time.

My main problem with db.js is transaction support. Currently, each db.js operation runs in its own transaction. This is nice for simplicity, but it completely kills performance. Try doing 1000 adds in a single transaction versus 1000 adds in 1000 different transactions.

The problem is, transaction handling is kind of messy. Compared to the current db.js, adding transactions to the API would be one more thing for users to worry about. And IndexedDB transactions are pretty confusing to work with due to how auto-committing works.

How might adding transactions to the db.js API work? Here’s one (probably stupid) idea. Currently, if you wanted to do 1000 adds, you might do something like this:

var promises = [];
for (var i = 0; i < 1000; i++) {
    promises.push(server.whatever.add(data[i]));
}
return Promise.all(promises);

But that uses 1000 transactions. Here's an alternative:

var tx = server.tx("whatever", "readwrite");
for (var i = 0; i < 1000; i++) {
    tx.whatever.add(data[i]);
}
return tx.complete();

This would do all the adds in a single transaction tx created by server.tx. server.tx is a wrapper around IDBDatabase.transaction which adds access to the object stores specified in the first argument and complete, a function that returns a promise that resolves after the oncomplete event for the transaction fires. And the first code example would still work just as it does today, the transaction API would be purely optional to use.

This API was not handed down to me on clay tablets from God. It's just an idea. The larger point is, something is needed to deal with transactions or it’ll continue to be impossible to write performant IDB-heavy apps with db.js.

Is there interest in adding something like this to db.js? Or do you see db.js as something that should not have this level of complexity?

allowing additional "resume" promise property for user to easily resume promise chain (if blocking undone by closing old db connection); Cache server by version as well as name to allow upgrades of same name (and document); Avoid apparently broken saucelabs directive in grunt processing; Minor: Utilize forEach over for loop; Minor: Replace "magic" numbers with descriptive vars. in open() testing Minor: Clarify delete testing by moving db opening to beforeEach (and add some content)

I recommend starting with the README as the main added features are described there.

Firstly, thank you for a great library. We've used this library successfully on a recent project at @EnableSoftware.

In the course of using this library, we've found a couple of issues which if addressed we feel will make the library even nicer to work with:

1. It seems that throughout the code, a string is thrown, rather than an Error (see, for example, A String is not an Error;
2. Code both rejects and throws;
3. In a number of places in the code, error handlers appear to be attached too late.

An example of these issues is the get() method on the Server object:

this.get = function ( table , id ) {
    if ( closed ) {
        throw 'Database has been closed';
    }
    var transaction = db.transaction( table ),
        store = transaction.objectStore( table );

    var req = store.get( id );
    return new Promise(function(resolve, reject){
      req.onsuccess = function ( e ) {
          resolve( e.target.result );
      };
      transaction.onerror = function ( e ) {
          reject( e );
      };
    });
};

Here we see that a string, rather than an Error is thrown. I believe that the first block in this method should be replaced by

if ( closed ) {
    throw new Error('Database has been closed');
}

or should return a Promise.reject() (see below).

Secondly, we see in the get() method that this method either throws, or returns a Promise. This means that calling code has to handle both cases. This means a try/catch and a .then()/.catch().

I realise that there is a school of thought that suggests throwing rather than rejecting, but this leads to, in my opinion, overly verbose calling code (the linked article acknowledges that this practice is controversial, and that some people recommend "Reject[ing] whenever possible, [as] it's more performant because throw breaks the stack.").

With our current codebase, we have had to litter our code which consumes db.js with lots of code like the following, just to handle both the errors thrown and the promises returned:

return new Promise(function (resolve, reject) {
    try {
        db.open({
            server: "name",
            version: 1
        }).then(function (s) {
            resolve(s);
        }, function (e) {
            reject(e);
        });
    } catch (e) {
        reject(e);
    }
});

It would be nicer if consumers of db.js only needed to handle the returned promise.

Finally, it appears that in some cases error handlers are attached too late. In the get() method, above, we can see that a error handler is added to the transaction after the call to store.get(id). It appears from our testing that this means that if an error is thrown during the get operation, it is not handled by the error handler attached to the transaction. It appears that this is a pattern that is employed throughout the code, not just in this get() method.

Given the concerns above, a re-factored get() method could look something like:

this.get = function ( table , id ) {
    if ( closed ) {
        return Promise.reject(new Error('Database has been closed'));
    }

    return new Promise(function (resolve, reject) {
        var transaction = db.transaction(table);

        transaction.onerror = function ( e ) {
            reject( e );
        };

        var store = transaction.objectStore(table),
            req = store.get( id );

        req.onsuccess = function ( e ) {
            resolve( e.target.result );
        };
    });
};

I believe that this addresses the concerns outlined above. Please let me know if any of this requires further information or examples.

I'm trying to insert multiple documents but are inserting only the first document. ex:

server.person.add({JSON1}).done(function(item){ server.person.add({JSON2}).done(function(item){ alert('ok'); }); });

The return is: [{JSON1}] Expected: [{JSON1}, {JSON2}]

is it something very wrong I'm doing? if you place the two in a json array inserts it more when I try to insert anything else he does not insert.

In README.md:

server.people.query( 'firstName' , 'Aaron' )
      .execute()
      .then( function ( results ) {
          // do something with the results
      } );

instead it should be:

server.people.query( 'firstName' , 'Aaron' )
      .all()
      .execute()
      .then( function ( results ) {
          // do something with the results
      } );

or:

server.people.query( 'firstName' , 'Aaron' )
      .filter()
      .execute()
      .then( function ( results ) {
          // do something with the results
      } );

I'm trying to write tests for features the require this library and IndexedDB does not exist in our test environment (Node with Domino JS).

We can easily swap out our implementation with a fake IndexedDB, but unfortunately, this library throws as soon as it's evaluated.

I'm considering a pull request that would lazily load the global reference to IndexedDB after the first request rather than immediately upon evaluation.

Thoughts?

…g (paralleling add() behavior), addressing issue #123; add test; simplify add(); rmv trailing spaces

Replacing outdated PR #131 .

Note that some dist/ changes appear to be due to my having just installed babel which was apparently a more recent version than that you used.

I'm using a function to open the database and try to use the assigned server variable in other functions:

var server;

function OpenDB() {
  db.open({
      .....
  }).then(function(s) {
    server = s;
  });
}

function DoSomethingInDB() {
  console.log("Server var:", server); <<<< undefined
  server.mytable.count().then(function(ct) {  <<<error: Cannot read properties of undefined (reading 'mytable')
    ...
  });
}

....

OpenDB();
DoSomethingInDB();

My database is successfully created in OpenDB(). Unfortunately, it seems that the global server var becomes undefined outside the OpenDB function. From documentation:

A connection is intended to be persisted, and you can perform multiple operations while it's kept open

But I didn't close it. Bah? For sure I'm doing something wrong. Can you help me? Thanks.

Issue:

Got an exception when tried to add listener to db. "undefined is not a function (evaluating 'a.addEventListener(b,c)')","name":"TypeError"}

How to reproduce on Safari of iOS 8/9:

var server;
db.open({
    server: 'my-app',
    version: 1,
    schema: {
        people: {
            key: {keyPath: 'id', autoIncrement: true},
            // Optionally add indexes
            indexes: {
                firstName: {},
                answer: {unique: true}
            }
        }
    }
}).then(function (s) {
    server = s;
   // The line will throw error
    server.addEventListener('versionchange', function(e) {
    });
});

There are a bunch of minor fixes or refactoring, testing, and doc improvements in this PR, but the main change in this PR is versioning of schemas. It is backwards-compatible, with the exception that now it will delete unused indexes by default (which I think should be fairly safe and fits in with the behavior that we auto-delete unused stores) and it will also destroy and rebuild stores if they are respecified with different options (e.g., a different keyPath). The README ought to be helpful in visualizing the new schemas (and schemaBuilder) formats.

• Fix: Ensure return after rejection (in get and count);
• Fix: Better type-checking for bad schema objects;
• Fix: Polyfill newVersion for PhantomJS
• API change (breaking)/Feature: Add clearUnusedIndexes option (defaults to true);
• API change (breaking)/Feature: Destroy and rebuild stores or indexes if present with different options;
• API addition: Support a schemas object keyed to version with values as schema objects. (Utilizes own IdbImport class, relying on own fork of idb-schema at least for now.); idb-schema callbacks will be passed db.js Server as second argument
• API addition: Support a schemaBuilder callback which accepts an idb-schema object for incremental, versioned schema building and whose addCallback method will be passed an enhanced upgradeneeded event object with a Server object as a second argument for making db.js-style queries (e.g., to modify store content), albeit with certain limitations. Along with schemas, addresses issues #84/#109
• API addition: Support a clearUnusedStores property to conditionally avoid deleting old stores.
• API addition: Add db.del alias of db.delete
• API addition: Add del() alias on Server for parity with idb-batch (likely to use or adapt for multiple change transactions);
• Feature: Change schema (and allow for schemas) to differentiate between "mixed", "whole", "idb-schema", and "merge" types with schemaType option (defaulting to mixed for schema and whole for schemas, maintaining prior behavior in backward-compatible manner);
• Docs: Update version and schema to take schemaBuilder into account (and document schemaBuilder).
• Docs: Expand on key behavior examples;
• Docs: Indicate that key is optional too
• Docs: Add mention of missing limit on modify
• Refactoring: Use const where possible;
• Refactoring: Change variable placement including reordering static variables according to type (built-in alias, IDB, immutables, cache)
• Refactoring: Avoid try-catch for brevity if will throw in sync body of Promise (but denote which lines may throw)
• Refactoring: simplify transaction building
• Refactoring: Add lang attribute for Atom linter-jade package;
• Code comment: preventDefault not only for Firefox.
• Code comment: Clarify how old connections may be closed
• Testing: Schema building tests
• Testing: Add tests for caching
• Testing: Add test:local and phantom on package.json scripts
• Testing: Fix server-handler test (expect specific error)
• Testing: Fix test-worker to deal with multiple babel-polyfill instances
• Testing: Remove redundant bad-args test
• Testing: Unregister service worker