Multiple indexedDB per app

[mattheffernan]

I know its not recommended but if there is a good use case for it, what is the least detrimental way of doing it?

[bramski]

You're gonna write a PR?

[mattheffernan]

It looks like the provider creates the $indexDb service and that is the instance/connection of the db.

UI router handles this by having a states collection off the $routes service. So what about having a DB collection off the main object.

Another option is to have the config wire up multiple services, so you have each 'named db' as an injectable service.

[bramski]

Can you answer my first question? I'm happy to help you out. But knowing if you intend to contribute this to the project will help color my answers to your question and what kind of suggestions I'm going to make about how I'd like to see this implemented.

[mattheffernan]

Sorry, yeah I would be happy to help. My only hesitation is my knowledge in coffee script is very limited but familiar with es6/ts and the syntax looks close.

[bramski]

Similar. Some gotchas. The main one being implicit returns.

My preference would be for the latter as it will allow for the best compatibility for everyone who only wants one indexedDB and allow their development lives to be very simple. I don't really like the design of UI router. I feel it is very obtuse.

In this case $indexedDB would always be the first database you have configured. All of the databases you have configured could be wired as indexedDB[databaseName].

[bramski]

would be nice to change the syntax slightly from the provider config.

angular.module('myModuleName', ['indexedDB'])
  .config(function ($indexedDBProvider) {
    $indexedDBProvider
      .connection('myIndexedDB').as('myIndexedDB') # defaults to what you name the database without using .as
  });
.controller('myControllerName', function($scope, myIndexedDB) {
  ... business as usual
}

[bramski]

Can I ask what your use case is for multiple DBs btw?

[mattheffernan]

Mostly experimental currently. I am thinking about an idea that would allow me to have an app that has structured application data (schema/metadata type data) and then have one or more separate databases that would allow the user to store there own data.

Sql Server does this where you have a master database that is structured and has a schema that explains the security, databases, jobs ect. Then there are user databases that each are wide open, store any data and has any schema.

By separating the business database from the user, each can apply versioning at there own cadence without impacting the other.

[mattheffernan]

I like the 'as' syntax concept, but connection returns the provider so there wont be a way to tie together the connection to the name.

angular.module('myModuleName', ['indexedDB'])
    .config(function ($indexedDBProvider) {
        $indexedDBProvider
            .connection('myIndexedDB', 'myIndexedDb') # defaults to what you name the database without using 2nd param
    });
angular.module('myModuleName')
    .controller('myControllerName', function($scope, myIndexedDB) {
        ... business as usual
    });

This will allow the naming to be tied to the connection itself.

[bramski]

Sure. As far as your contribution to this project, I'm not sure this is useful to anyone but yourself. Feel free to make changes and fork the project, but I'd want some idea that other people are interested in this functionality or that you're using it in a production system to incorporate it into the project. Otherwise "experimental" contributions aren't going to add much value and will just destabilize and add complexity to the codebase.

Not trying to devalue your idea, just stating that you'll need to illustrate some value for the feature for me to merge it into the main project at a later date. Have fun experimenting in the meantime!

[mattheffernan]

Its cool, its an abstract idea. But if you want users to be able to load there own unstructured data into your site or create there own schema you have to separate out the versions since each user might be on a different database version. So your app might be on version 3 but your user has made 10 changes to there own database and is on version 10. If you upgrade the core app to version 13, when you put in the next change (version 4) the app has no way of knowing if that change has been applied or not since there are dynamic versioning that is firing outside of the normal flow of the app.

Mongo gets around this by allowing collections to be created without the concept of a version number, so you can make indexes or collection changes on the fly.

[bramski]

IndexedDB supports that. This project does not support dynamic schema
changes at this time though.
On Nov 10, 2015 1:40 PM, "Matt Heffernan" [email protected] wrote:

Its cool, its an abstract idea. But if you want users to be able to load
there own unstructured data into your site or create there own schema you
have to separate out the versions since each user might be on a different
database version. So your app might be on version 3 but your user has made
10 changes to there own database and is on version 10. If you upgrade the
core app to version 13, when you put in the next change (version 4) the app
has no way of knowing if that change has been applied or not since there
are dynamic versioning that is firing outside of the normal flow of the app.

Mongo gets around this by allowing collections to be created without the
concept of a version number, so you can make indexes or collection changes
on the fly.

—
Reply to this email directly or view it on GitHub
#51 (comment)
.