I decided to use indexeddb to store data for a chrome extension I wrote. I've noticed that if I remove the extension and readd it, the data is lost.
Is there a way to persist the database across re-installations?
The apps docs (which also applies to extensions) recommend using storage.sync to handle persistence across re-installations, but the quota is very limited: 102,400 bytes. And it's not the same thing as indexeddb so some data processing would need to be done.
If your data is bigger than that I think the only solution is to sync your data manually with a server-side component, either your own or some other cloud-based solution like Firebase:
https://www.firebase.com/blog/2013-03-06-power-your-chrome-extension-with-firebase.html
Indexeddb is temporary storage. https://developers.google.com/chrome/whitepapers/storage
Browser may clear data anytime as necessary.
Until persistent data storage is available, possibly in combine with quota management api, treat indexeddb data as temporary.
Related
I want to build a hybrid using Ionic/Electron to run it on Desktop,Browser and Android, after doing some research i found about RxDB which by it's definition seems to fit this kind of DB usage (https://rxdb.info/)
I want to be able to store data locally in an SQLite-like storage capacity without being limited by the web browser's storage capacity and use the same api (rxdb ?) to manipulate data on Desktop (Electron), Mobile and web browser (Ionic).
Is this possible using RxDB ? if it's not i would like to know if there are tools out there capable of allowing such functionality ?
Yes this is surely possible with RxDB, you can use IDB which stands for indexed data storage, which in terms of browser means that your data will not be limited by the browser capacity, since it is stored offline in your computer,
It is limited only to your available disk space Not to the browser capacity
That is what idb adapter helps in browsers
Please tell me what is normally a data store, large data in Google's extension. I know there is a chrome.storage - now I keep everything in it - a couple of keys. But to make a selection, etc. not convenient from the word at all, there is a possibility that the data will be lost, etc.
I know there is WebSql and indexedDb, but they are declared deprecated. Can eat still variants? excluding a separate server that will store all the data in the mysql database.
There is comparing about localstorage with chrome storage. You can easly decide which is better.
window.localStorage vs chrome.storage.local
For small amounts of data you have "localStorage" which is usually 5 Mb, and you have "chrome.storage" which has 5 Mb locally and a part of it can be uploaded to Google servers (for cross-browser sharing) - on the server you have just 100 Kb.
Then there's IndexedDB, which seems to vary from 10 Mb up to 300 Mb and maybe even a bit more. See Maximum item size in IndexedDB
and this document which describes quotas on IndexedDB.
If you want to treat a lot of data, you have to either upload it to your (or a 3rd-party-provided) server-side database, or create a normal desktop app (if you want it locally).
I am working on a chrome extension for managing sessions.
I would like to store some data related to sessions and this is what I have found out till now:
1) Local Storage: Looks good to me, but I am afraid I may have too much data, and there seems to be quota on the storage. Also, local storage is more of a long-term cache, not too much dependable.
2) SQLite: not sure how it works. Need more advice on this.
3) Chrome Filesystem API: Available only on apps, not extensions.
4) HTML5 Filesystem API: Works on a virtual file-system
Please advise on the possible options.
What about the chrome.storage API? https://developer.chrome.com/extensions/storage
How about IndexedDB,
It's known for being great for client side apps, and has Unlimited space to store anything type of data you want.
We want to implement caching in Azure for two main reasons:
Speed up repetive data access
Reduce stress on the database
Here are the characteristics of the data we are planning to cache:
Relatively small (1 - 100 kb)
Specific to each customer
Not private, but we don't really want random people navigating through our entire cache
XML or JSON
Consumed by C# (i.e. not linked to directly in the html)
Most weeks the data will not change, although some days the data could change several times
For this specific purpose Table storage appears better than Blob storage (we did just implement Blob storage for images, CSS, and JavaScript) and Windows Azure Caching appears better than Windows Azure Shared Cache (perhaps almost always better and the shared caching is mostly a legacy feature at this point).
The programming API of both appears straight forward. Compared to what we pay for cloud sites the cost of each seems to be negligible.
So far we are leaning toward Table Storage due to what we perceive to be the pros and cons of Azure Caching. As old .Net guys we are much more familiar with In-Memory Cache than NoSql style solutions:
Problems with Windows Azure Caching:
If the VM is moved to a different server (by Microsoft for load balancing or whatever reasons) is the in-memory cache moved intact?
We are guessing that whenever we publish changes to the cloud it wipes out the existing in-memory cache
While the users rarely make changes to the cached data when they do make changes it is likely that they may make multiple updates within seconds and we are not sure how this is going to work with cache located across multiple nodes running web roles especially with increased traffic. (this is probably a concern with table storage as well!)
Table storage appears like it will be easier to debug
Advantages of Windows Azure Caching
somewhat faster
Your familiarity with in-memory caching is the model that you need to understand to implement caching on Windows Azure. The 'NoSql style' is not caching, but storage. So table storage rather replaces SQL than it replaces caching. Table storage is for persistent, reliable storage — with all of the latency and other disadvantages of persistence that do not exist with in-memory cache.
Writing to cache is always secondary. When your users 'make changes to the cached data' you will always be writing out the data to disk (e.g. SQL), and then writing out the same data to the cache because you might as well, since you have the data on-hand (although secondary effects on written data may mean that you should invalidate or re-read the cached item).
The wiping out of data when a machine recycles should not be much of a concern, as the data is stored elsewhere. Every read from the cache should be followed by an 'if not found then read from database' kind of statement. You can warm-up the cache when a role starts to pre-populate items that you know that you are going to need.
Caching on Azure is distributed across the nodes and updating an existing item will always update on the node that it resides. Quick updates may be less of a problem than you think.
For in-memory caching use Windows Azure caching (you are right about shared caching being legacy) and, depending on your needs, look at other caching technologies like memcached. Caching and table storage are not comparable. Table storage is for long-term persistence. Don't unnecessarily hack table storage to do caching — making table storage temporary creates a whole bunch of things that you need to worry about yourself, like expiry and invalidation.
I have a Phonegap/Cordova app that runs on iOS. It saves it's data into HTML5 localStorage.
I'm trying to work out if it's possible to sync the localStorage data (using iCloud) to other iOS devices, and even OS X.
From what I can see, in iOS localStorage is actually implemented as a SQLite database, which (when using Phonegap/Cordova) is written to the app's Documents directory:
Documents/Backups/localstorage.appdata.db
I also understand that there are three main ways of storing data in iCloud:
Key/Value storage
UIDocument / NSDocument
Core Data
I know I can't use the Key/Value iCloud storage method, because I have more than 1MB of data to store, and the limitation is 1MB per app with that method.
This question, I believe is talking about the UIDocument method, and asks if it is possible to store a SQLite db file in iCloud using that method. The answer is no because the database may become corrupted.
So that really leaves the Core Data method.
So my question is - would this work? Could I sync the localStorage.db file to iCloud using Core Data?
I've never used Core Data and don't know much about it. I'm just wondering if it would be possible, or if there is something else I don't understand.
Are there any other ways to sync localStorage data between iOS devices or OS X ?
The answer unfortunatly appears to be no, Core Data cannot be used with HTML5 localStorage
Core Data can not be used with SQLite databases other than ones created with Core Data. If you try to, you get this error in XCode:
SQLite error code:1, 'no such table: Z_METADATA'
This is explained the Core Data docs:
https://developer.apple.com/library/mac/#documentation/Cocoa/Conceptual/CoreData/Articles/cdFAQ.html#//apple_ref/doc/uid/TP40001802-SW2
Although Core Data supports SQLite as one of its persistent store
types, the database format is private. You cannot create a SQLite
database using native SQLite API and use it directly with Core Data
(nor should you manipulate an existing Core Data SQLite store using
native SQLite API)
I still want to solve this issue though. I'm thinking of creating a Javascript API that mirrors the localStorage API. This would be a phonegap plugin that can call objective-c code, and effectively write it's changes to a Core Data database. The Core Data database should then be able to be synced to iCloud.
If it works, I'll come back and update this answer.