Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Database persistence #299

Open
pentacular opened this issue Sep 12, 2023 · 2 comments
Open

Database persistence #299

pentacular opened this issue Sep 12, 2023 · 2 comments

Comments

@pentacular
Copy link

Is your feature request related to a problem? Please describe.

Is there a way to specify database persistence?

Describe the solution you'd like

I would like a way for "Is persistent" to show true in chrome's debugger Application > Storage > IndexedDB tab.

A way to prevent DB eviction without user action.

@dustinbolton
Copy link

dustinbolton commented Oct 6, 2023

In most browsers the best you can do is request the browser not evict data for the site. Some browsers prompt the user for allowing this. The MDN docs for "Storage quotas and eviction criteria" is helpful.

It's important to note that Chrome will default to refusing to allow setting data to persist if there is not sufficient user interaction to tip the scales so the request should not be ran on page load or similar. Good news is that despite this it looks like data is rarely evicted even without persist set. You can read more from Chrome devs here.

It could be handy to have a method in this library to handle this but there are limitations since it's not guaranteed to be accepted and care should be taken on when it would be called. Additionally, the persist option extends beyond IndexedDB to other things like cookies, cache, local storage, and more. If this gets added I'd recommend noting the limitations and best practices mentioned above in the documentation. Otherwise the following should be helpful.

Example to check if data is set to persist (source):

if (navigator.storage && navigator.storage.persist) {
  navigator.storage.persisted().then((persistent) => {
    if (persistent) {
      console.log("Storage will not be cleared except by explicit user action");
    } else {
      console.log("Storage may be cleared by the UA under storage pressure.");
    }
  });
}

Example to request the browser set data to persist (source):

if (navigator.storage && navigator.storage.persist) {
  navigator.storage.persist().then((persistent) => {
    if (persistent) {
      console.log("Storage will not be cleared except by explicit user action");
    } else {
      console.log("Storage may be cleared by the UA under storage pressure.");
    }
  });
}

@caboodal
Copy link

caboodal commented May 8, 2024

We've been using this library for several years but recently in the last 12 months or so have had users reporting total data loss scenarios where they have added information to the database but then upon revisiting the app a few days later everything has gone. Initially we thought it could be user error but the problem seems to be fairly constant in that it continues to be reported and it is completely impossible to replicate or debug.

As per usual as users are not always great at reporting the issues or being particularly accurate with their descriptions but we are beginning to feel that there is an issue with the persistence of data within the IndexedDb storage. We are now at the point where we feel we need to completely remove the offline capability of the app and return to a client/server get/request approach to persisting data and abandon our offline feature.

Has anybody else had issues with data loss like this?
Has anybody got any suggestions as to how we could monitor or trace activity in an attempt to diagnose the issue?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants