There is a lot of confusion when it comes to ionic 2 storage. There was a lot of changes in the new ionic version as Storage was moved to #ionic/strage . I am new to Ionic so some of the things are confusing for me. I have web-development background. From the documentation,
A simple key-value Storage module for Ionic apps based on LocalForage,
with out-of-the-box support for SQLite. This utility makes it easy to
use the best storage engine available without having to interact with
it directly. Currently the ordering is SQLite, IndexedDB, WebSQL, and
LocalStorage.
Installation
npm install #ionic/storage
If you'd like to use SQLite as a storage engine, install a SQLite plugin (only works while running in a simulator or on device):
cordova plugin add cordova-sqlite-storage --save
What I would like to know is, what happens when I run this in browser ? Where does it store the data? What would happen if I dont use cordova-sqlite-storage ? Where does it store the data then?
Ionic also supports SQLite plugin natively to store data in SQLite database .
import { SQLite } from 'ionic-native'
How is it different from Storage other than the fact that there is a fallback to IndexedDB, WebSQL, and LocalStorage ?
I hope my thoughts are in the right direction. A clear answer on how these modules work would be really helpful.
Ionic Storage is the first module written with proper web fallback in mind.
One near-term goal we have with Ionic is enabling devs to build 99% of their app in the browser. It's a much faster workflow. This means support for native plugins that have web fallbacks, as well as better mocking for ones that don't. - Max Lynch on Twitter
By default when running, #ionic/storage will prioritize the storage methods this way:
When running in a native app context, Storage will prioritize using
SQLite, as it's one of the most stable and widely used file-based
databases, and avoids some of the pitfalls of things like localstorage
and IndexedDB, such as the OS deciding to clear out such data in low
disk-space situations.
When running in the web or as a Progressive Web App, Storage will attempt to use IndexedDB, WebSQL, and localstorage, in that order.
- Official Documentation
So when your app is running in the browser (or on a device without the SQLite plugin) it will detect that SQLite is not available and will use IndexedDB/WebSQL instead.
How is it different from Storage other than the fact that there is a fallback to IndexedDB, WebSQL, and LocalStorage?
The SQLite plugin gives you low-level access to an SQLite database, which means you have to care about creating/updating your schemas, and write queries.
#ionic/storage is a wrapper which abstract away the differences of LocalForge and SQLite and provide a simple, unified API to store key/value pairs.
Also it takes care of serializing/deserializing of your objects.
From my understanding of the Ionic 2 RC Storage module, when you are running in the browser you are now only able to store key-value pairs (LocalStorage). You are currently not able to store anything more than that, so you should check out other options like PouchDB and LocalForage if you need full SQL support. This definitely isn't ideal for progressive web apps.
Related
If I use Realm in my SDK, when someone embed's my SDK in their app and they are also using Realm would there be any conflict? or am I better off just sticking to CoreData.
I'm looking at moving to Realm because I like the thread safety aspect of it and the number of queries it can perform per second.
If you ensure that you use a custom Realm database - not the default - then you should be okay to use Realm in your SDK. Projects can contain multiple Realm databases without a problem.
I've been looking into the Phonegap and PouchDB docs for days but I don't seem to get a clear answer.
Is it correct that when I add the Cordova plugin Cordova-sqlite-storage and use PouchDB using the PouchDB API, I'll have unlimited storage in my iOS webview?
I'm actually confused since I thought PouchDB was based on CouchDB (which seems like NoSQL). SQLite is using SQL queries for data storage.
Thanks!
Yes, you don't have traditional storage limits when using cordova-sqlite-storage. I've worked on an app that's in the App Store and Google Play today that uses >100Mb of data in SQLite. Cordova documentation backs this up.
PouchDB has a SQLite adapter which you might be able to use but I have no direct experience here and the documentation notes you should only use it with SQLite unless you really need >50Mb storage as there can be performance issues.
LokiJS with persistence might also be an option for you.
I'm planning to work on a social site and I would like to leverage both a document and graph database for all of the desired features. Is there a way to get Meteor.js or Sail.js (or any better) to work with ArangoDB or OrientDB? Or should I just stick with the bundled MongoDB and integrate something like allegrograph DB?
Sails.js has support for both of the databases you mention:
https://www.npmjs.com/package/sails-orientdb
https://github.com/rosmo/sails-arangodb
In addition to MongoDB, Postgres, and dozens of others.
Sails.js is a classic mvc client-server web application framwork, basically its ruby on rails implemented for node.js + webscockets, so mostly all you need to make it work with any backend database is make changes to the orm.
Meteor is a very different beast, it is a very opinionated realtime end to end web framework including client server and database, by behing very very opinionated it solves many of the common issues in realtime application, where you need to implement a mechanisms for very quickly updating all your clients of each others actions and take care of things like latency compensation, data collision resolution, and real time client version managment, This is implemented by using web sockets and the mongoDB's write ahead logging for triggres of data updates, making meteor somewhat coupled with mongo.
But you can make orientdb work pretty well with meteor using the new orientDB live query api. It is a pubsub implementation for query results, and can be used for efficent updates pushed from the db through the server directly to the client with very little overhead on the server. This is far from production ready and only currently works on the orient db 2.1 rc5 version.
I have implemented a small meteor demo application as an example https://github.com/imdark/meteor-orientdb-demo
Please check on Meteorpedia the Alternative Database Post, they mention neo4j-livedata and minineo4j.
Here is the Atmosphere package: ostrio:neo4jdriver
Is there a specific economic or technological reason why you consider not to use the very well integrated mongoDB as the database of choice?
In addition to Travis answer I also recommend waterline-orientdb for Sails.js.
A rookie question. Can any one explain when it is better to go with SQLite storage in sencha touch and when to go with use data stores.
regards,
I don't think they are mutually exclusive.
Sencha Touch stores come into their own when you have any kind of data that needs displaying in the viewport (and that data might change)
Sencha have a sql proxy that will work on these stores with a browser's websql implementation or a native app's sqlite implementation (with the aid of a cordova/phonegap plugin)
The main reason why you'd use SQLite on a native app is to circumvent the 5mb localstorage limit. You can't get around this limit for webapps though.
Pardon if this sounds noob.
We are current working on a mobile application that utilizes the Cordova framework. We would need to store data on the device, and such had decided on to use a database system.
We understand that for db storage, Cordova supports the WebSQL API, but since currently W3C stopped the development on WebSQL, we would wish to use a native SQLite database.
However, we do have a database file that are created via the WebSQL API. I understand that WebSQL actually utilize SQLite underneath(correct me if i'm wrong), but would the file display the characteristic of a WebSQL database? such as the file size limitation on mobile device?
The file size limitation is implemented in the particular copy of the SQLite library that is used to access the database, not in the database file itself.
Please note that W3C's (lack of) endorsement does not necessarily influence whether Cordova continues to use WebSQL.