Making the indexeddb adapter publicly consumable #7618
Conversation
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
No we definitely want to do this, I just need to not be crushed at Normal Work™... |
|
@SCdF I'm ~1-2 weeks away from initial release and I'm not sure if I should switch to the new adapter or stick with the current for now. AFAIU those are not compatible and there's no way yet to easily upgrade dbs on switch. What would you recommend? |
|
@alexfedoseev for now I wouldn't, though I would greatly appreciate any testing you want to perform! Unfortunately getting this merged is a secondary concern for me as there has been some Super Urgent Critical™ stuff at work for the past few months that has reduced my ability to contribute here. I'm hoping in a month or so I can get back on track and find the time to fix the build and get this work moving again. On the migration, worst case the recommendation would be to replicate between the two to perform the migration, but I'm hopeful that it's not that much pain to just alter the internal structures. I haven't looked into it deeply yet. |
|
@SCdF Thanks for the feedback! I will stay on the current version then. I’m not familiar with the way pouchdb gets built. If you can give me some pointers how can I consume next adapter, I’ll check it out sometime. Api is the same, right? |
|
@alexfedoseev unfortunately it's hard to use the new adapter right now (this is what this PR is meant to solve), you need to basically use the hidden NEXT=1 build, which I do not believe is possible via standard npm-based imports. |
idb can't open indexeddb dbs because the version is too old. We detect
that and generate a useful error to the user, which happens when you
try to instantiate the handle (new PouchDB(..))
for indexeddb we check to see if the old version is in the range that
idb occupies but indexeddb never does. Unfortunately due to indexeddb
lazily opening handles this only happens once you actually perform
an action on the DB (dbhandle.post({foo: 'bar'}))
|
@daleharvey / @garrensmith so I think this is ready to look at. I have no idea what I'm doing, and I don't actually know if this will expose this adapter on npm once a publish kicks off. I also fixed the Chrome tests, and they now run on Saucelabs. This change contains a very large travis yml, which basically tests everything on both adapters (new and old) as well as on Chrome and FF. I think at a minimum we should keep that latter change (everything on Chrome and FF) since they are both important browsers. |
| // adapter? | ||
| // Note that we're no longer invoking that adapter by passing NEXT=1, so | ||
| // this code isn't firing. If these tests work with indexeddb builds on travis | ||
| // we can drop this. |
|
Sorry for the long long delay here, in future feel free to 'timebomb' these commits, ie if you dont get a timely review (2 weeks) and have commit access, feel free to land So I think this is very nice, we can drop the autoCompaction thing as you mention, the one issue is I would like to avoid adding a whole bunch of new test runs, especially if we need to move chrome to saucelabs for now We dont need (and will never get) full coverage, while We can take out the AUTO_COMPACTION runs completely at this point since nobody has touched that code in a long time |
|
Tell you what, lets merge this and can drop the uneeded test runs in a follow up |
|
(Hey! Sorry I was so delayed following up with this, I've been travelling for work and hadn't found time to read your comments yet. Thanks for the merge!) |
* Remove the private flag to we publish this adapter to npm
* Stopping idb and indexeddb from opening each other
idb can't open indexeddb dbs because the version is too old. We detect
that and generate a useful error to the user, which happens when you
try to instantiate the handle (new PouchDB(..))
for indexeddb we check to see if the old version is in the range that
idb occupies but indexeddb never does. Unfortunately due to indexeddb
lazily opening handles this only happens once you actually perform
an action on the DB (dbhandle.post({foo: 'bar'}))
* Removing NEXT generation
* Apparently my editor's eslint plugin is broken again..
* Update travis to also test indexeddb adapter
* Does changing all chromes to saucelabs magically work with no additional effort?
* Dropping chrome_bin
* More debugging on selenium / sauce connections
* Removing unneeded logging
It's time to take indexeddb out from under NEXT=1 and into the spotlight. Or at least the
npm installlight..This PR is attempting to do such a thing. I am probably missing steps. For now I'm creating this PR so travis runs tests, as it seems profoundly disinterested in this branch otherwise.
Things done in this PR:
idb-created DB with theindexeddbadapter errorsindexeddb-created DB with theidbadapter errorsprivateflag from the adapter, which I presume is all I need to do to enable eventual npm publishingI'm not sure what to do about that last one. We really should be testing each supported adapter in each supported browser, but that's a matrix of doom. This will drop down once we drop / deprecate
idbsupport, but there are still lots of combinations we're not testing here (eg most of Safari).