IndexedDB - Drop database instance created by IndexedDB upon browser clear cache - google-chrome

The database instance created by WebSQL API is dropped automatically once browser cache is cleared (chrome://settings/clearBrowserData) but when database instance created by IndexedDB API, then it is not dropped upon browser clear cache. So when same domain is navigated then db instance created before browser clear cache can be seen.
I have tried all the techniques mentioned in how-to-delete-indexeddb-in-chrome, like going to content setting but they really don't work + they are manual step. I want the cache to be cleared using chrome://settings/clearBrowserData, which works well in case of WebSQL.
Only way I could make it work in case of IndexedDB is by programmatically dropping the db instance (indexedDB.deleteDatabase("my_db_instance")), but that doesn't fit good in production environment for end users.
Is it a know or unresolved issue? Thoughts?

Make sure "Cookies and other site and plug-in data" is checked before hitting the "Clear browsing data" button. If that still doesn't work then please file a bug that includes reproduction steps.

Related

Google Sheet Stuck and unable to update, too many old versions?

TLDR:
Our Google Spreadsheet is broken and cannot be edited / saved. It keeps saying Trying to reconnect. To edit offline, turn on offline sync when you reconnect, and Reconnecting. Can it be due to the many versions saved? If so, what can be done if we don't want the sheet to change its ID?
Any help is highly appreciated!
Detailed Background:
We have a large Google Spreadsheet in our project (< 700k cells) and it's well under the 2 million cells size limit as described in here .
We have been programmatically updating this sheet by creating CSVs in the google drive with python, then using Google App Script to update the sheet with contents from the CSVs.
It has been fine for several weeks, today we started to have an issue, that is, when we manually open the sheet, it just keeps saying "Trying to reconnect. To edit offline, turn on offline sync when you reconnect", and "Reconnecting". We can make no changes to the sheets.
We tried to use different browsers (chrome, firefox, edge) and different OS (Windows, Mac), and we still have the same issue. So I don't think it's anything related to firewall / browser configuration.
We tried to make a copy of the sheet, and we are able to make changes to the copy. We can also access any other sheets and make changes without any problem.
The only difference between the actual sheet and the copied sheets is probably that the actual sheet has a lot of old versions (it has been updated every 3 minutes for weeks). Can that be a reason of failure to edit?
Another possibility is that many other scripts read this sheet. Can this be why? (It will be a pain to stop all the scripts / redirect all the scripts to another Spreadsheet)
Thanks a lot in advance!
Additional Details / Conclusions:
Using a database is definitely a better idea than a spreadsheet for such a large scale dataset.
An ".edu" domain was used. I believe we are using the G Suite version.
Just like the PC case, I am unable to make any changes when I use mobile version on Android.
From various sources, it seems that the old versions cannot be deleted (http://www.sevenminutescientist.com/2016/06/03/no-you-cannot-remove-a-revision-history-from-a-google-doc/)
When I look into the version history, it shows the following: "Google Docs encountered an error. Please try reloading this page, or coming back to it in a few minutes." I am unable to access any of the old versions.
Having issues with Google Drive constantly disconnecting you in Chrome? Error message: “Trying to connect. To edit offline, turn on offline sync when you reconnect”
This issue was encountered on a PC running Windows 10 64bit and Google Chrome (happens in the 32-bit and 64-bit versions). It doesn’t appear to happen in Firefox.
Cause: Kaspersky SSL Scanning (although it may still be an issue in Chrome as it doesn’t happen with other browsers and will likely be fixed by one of the parties soon)
Solution: Disable Kaspersky 2015 Encrypted Connection Scanning. Settings > Additional > Network > Disable encrypted connection scanning. NOTE: even if you disable Kaspersky via the temporary disable feature Google Docs still doesn’t work you have to turn off Encrypted Connection Scanning as it’s obviously always running even when Kaspersky is temporarily stopped (another bug as turning Kaspersky off should disable this).

indexedDB in a Chrome App

I'm building a chrome app which requires a persistent and local database, which in this case can be either indexedDB or basic object storage. I have several questions before i begin developing the app:
Is it possible to persist indexedDB data after un-installation of the chrome app and chrome browser?
If the indexedDB file/data persist can i locate and view it?
If I can locate but can't view it, is it possible to change the location of the indexedDB file?
Can I store the indexedDB in a file located on desktop or any other custom location?
If I had these requirements, I see a couple of options that you might pursue
Write a simple database backed by the FileSystem API, and periodically lock the database and back up that file. This would be pretty cool because I don't know of anyone who has implemented a simple FileSystem API backed database, but I could see it being useful for other purposes.
Any edits to the database would be also made to a copy of the database stored on your backup server, and I would write functions that could import snapshots from your backup.
Simply write functions to export from your indexedDB to some format into a backup, and to import from the backup.
All options seem quite time consuming. It would be cool if when you create an indexedDB, you could specify an HTML FileSystem API entry file to back it, and that way you wouldn't have to do 1 or 2.
I agree that it seems like quite an oversight that an indexedDB is quite difficult to back up.
I am writing a basic browser only application. No back end server code at this time. So I also have storage requirements. But I am not doing backup. I am looking at pouchdb as a solution: http://pouchdb.com/
Everything is looking good so far. They also mention that they would work well with Google Apps.
http://pouchdb.com/faq.html#native_support
The nice thing is you could sync your pouchdb data with a server couchdb instance.
http://pouchdb.com/api.html#replication
http://pouchdb.com/api.html#sync
If you want to keep the application local to the browser with no server support you could backup the entire database by using a batch fetch.
http://pouchdb.com/api.html#batch_fetch
I would run the result through gzip before you put it on the filesystem.
I am currently attempting this very same thing. I am using the Chrome Sync File System Api (http://goo.gl/5q8Z9M), but running into some instances where my file (or its contents) is deleted. With this approach I am writing out a JSON object. Hope this helps.

PhoneGap Offline Caching json data

I'm building a Phonegap application and i'm planning to set it to work in both Offline and Online mode, the idea is to get JSON Data from a PHP server side script and show it in the application, these data contains text, images so my question is is there anyway to set a dynamic cache manifest or any other way in a way that the user can see the already loaded data when he's offline, like caching the json result itself or anything else you can help me with
thanks
What do you mean by "work in both Offline and Online mode"? Are the users able to only see the user created data or can they modify it too? Is it correct to use a Manifest to control caching of user created data? I would have thought you should only really use it for caching the application templates and code. In any case I think you'll probably need something that you can exert more control over, something based perhaps using WebSQL, IndexedDb or LocalStorage.
I have been working on the modify-it-too question for many months and have a solution in the form of javascript(phonegap) <-> server synchronization that works somewhat like a version control system, with version numbers and conflict resolution. There's some pretty great docs and demo on the GitHub page and you can even see a presentation courtesy of SkillsMatter / LondonAJAX.. Currently there is only a JS/Node based server but I will probably do PHP based server because that's my day job If you look at the server code it's pretty easy to implement.
BTW I would use a different method to store the images, why not just download them and store them in a File, I don't know the storage limits, but I bet that is the way that Phonegap will let you get away with most.

Losing data between updates (chrome packaged app)

I'm working on a chrome packaged app that saves a lot of data locally. I recently put it on the chrome store. To my dismay, whenever my user's chrome installation updated the app (v1.1.1 to v1.1.2 for example), all their local data was gone (indexeddb data). Why is this so?
Is it the expected behavior to wipe out all the databases on an update?
Is there any way to prevent this other than not pushing out updates?
(Also where can I report this issue/bug, if it is one?)
Update: filed a bug report, but now I can't reproduce the issue. Not sure if it was fixed or my situation was a fluke.
The documentation is fuzzy on this:
https://developer.chrome.com/trunk/apps/app_lifecycle.html
Preventing data loss
Users can uninstall your app at any time. When uninstalled, no executing code or private data is left behind. This can lead to data loss since the users may be uninstalling an app that has locally edited, unsynchronized data. You should stash data to prevent data loss.
I hope they will elaborate on this, because zapping user data on every upgrade is not a great user experience.
I put in an issue:
http://code.google.com/p/chromium/issues/detail?id=169417
one of the developers got back to me and said:
I can't remember the release numbers off the top of my head, but at
some point when we turned on correct partitioned storage, there would
have been one-time data loss. This was done before packaged apps
rolled out officially to stable. If the loss of data happened across
an chrome upgrade, then I would say it's expected. It certainly
shouldn't be happening anymore.

How to have database (mysql) snapshot for each bug submited

I am trying to find a way/tool to be able to do the following:
testers are testing the application on the main testing environment and find a bug.
They would generate a snapshot of the db used and attach it to the bug
Developer when working on the bug would be able to load this snapshot somewhere on the development server and used the instance created to work on this bug
Once the bug is fixed (and tested successfully) the instance created on the server would be destroyed.
The only thing I could think of is using Virtual Machine. Each developers would have a VM instance on the dev server and would be able to load snapshots of the bug they are working on in it. But this mean taking a snapshot of the whole environment (which is big). More over the testing are done on the dev server which is a replica of live. So nothing is changing except the db/middleware and front end.
I would love to be able to find a tool that would permit to just create/load snapshot of db (and even maybe middleware) and lets devs (so per dev instance) choosing which snapshot they want to work with.
Do you have any ideas of such tools or ways to do so?
I've tried to look around but haven't found anything helpful really.