add - Converting Firebase Database to Cloud Firestore





collection google (7)


The two database have totally different data models. For this reason, currently firebase is not offering an automatic migration tool, it would result in inefficient data structuring in many cases.

In the near future they will publish a guide detailing best practices for RTDB developers looking to use Cloud Firestore, so look out for that!

source link - google firebase group

Firebase Realtime Database:- All Firebase Realtime Database data is stored as JSON objects. You can think of the database as a cloud-hosted JSON tree. Unlike a SQL database, there are no tables or records. When you add data to the JSON tree, it becomes a node in the existing JSON structure with an associated key. You can provide your own keys, such as user IDs or semantic names

Example
{ 
   data: {
           first: "foo",
           last: "bar",
           dob: 1993,
         }
}

Cloud Firestore:- In Cloud Firestore, the unit of storage is the document. A document is a lightweight record that contains fields, which map to values. Each document is identified by a name. A document representing a user alovelace might look like this:

document
first : "foo"
last : "bar"
dob : 1994

One more thing in cloud firestore, the data model are stored into collection and document, and Realtime Database has no such concepts.

May all of you get Good News about Cloud Firestore by Firebase.

As I want to convert my Firebase Database to Cloud Firestore is there any simple way to convert It?

I want to move on Cloud Firestore.




Upgrade existing realtime firebase database into Cloud Firestore

You can certainly write code to copy your data from one place to another. There is no automated process, since the two databases are designed very differently from each other. You will need to make decisions about how to structure your collections and documents in Firestore, because Realtime Database has no such concepts.

https://firebase.google.com/docs/firestore/firestore-for-rtdb




I don't recommend you changing now, its is still in its BETA version and they are coming up with new things every now and then. I suggest to wait. Let them make up their mind first :P




Firebase has published a guide for migrating from Realtime Database to Cloud Firestore.

Edit: It seems they have changed that page. Here is a cached version of their migration guide published earlier.




Since the data models are so different, there isn't an automatic way to achieve this. You'll need to write your own method based on the needs of your app.

The documentation provides an overview of the differences.




I write myself guides as I learn new things. Here's my guide describing how I migrated my Realtime Database to Cloud Firestore. You can skip the first section. I write in Markdown, some of the code markup doesn't translate to 's markup. If you have trouble reading it I'll email you the original Markdown version. Now I'm working on updating my controllers to Cloud Firestore queries.

Migrating from Firebase Realtime Database to Cloud Firestore

Why, and why not, Firebase Realtime Database?

For more than two years my go-to stack has been Angular and Firebase. Data binding caught my eye--if a user changes data in the view, the data instantly changes in the controller and in the cloud database. Or any other order of events. My first Firebase project was a tic-tac-toe game where two players could play remotely, with my click appearing instantly on your screen, and vice versa, with the cloud database updating in between. (Firebase calls this "synced states across clients in realtime.")

I also like Firebase's Auth library. Setting up OAuth2 user login wth Facebook, Google, Twitter, GitHub, or a phone number, or old-school email and password, is easy.

I like not having to deal with setting up and maintaining a server.

And I like using a NoSQL database. I use arrays of objects in JavaScript, so why not use the same data structure in the database?

I don't need this, but mobile app developers can use Firebase Realtime Database's off-line capabilities. When the user is out of service range, the database can continue to update, so that when the user comes back online he or she can access current data.

Plus Firebase has Storage for large binary files such as pictures, audio, and video.

What's not to like about Firebase Realtime Database? The queries. My dog has so many neighborhood girlfriends that I need a database to keep track of them all. I want to call China's owners to invite her over for a play date. To get their phone number isn't easy. I can't tell Firebase to look in the array dogs, find the object with name equal to China, and return the field phone_number. I have to tell Firebase to download the entire array, then run a forEach loop to iterate over each object, looking for name === China. This is called a "deep query" because it returns every object in the array, and every sub-array, and all the nested sub-levels. My dog has so many girlfriends that it can take seconds to download them all!

Firebase Realtime Database has sorting, so I can download the array of neighborhood dogs ordered by name, age, etc. I can filter, e.g., only dogs more than five years old, but Firebase Realtime Database can't sort and filter.

The key to finding a specific object in the Firebase Realtime Database is to know its key. Keys are lightweight objects that look like -KloeQHDC-mugPjJMAG4. If you keep track of an object's key, you can easily retrieve the object from the database. E.g., when a new user logs in with Facebook and creates a record in the Auth database, and you then create a user account in the Realtime Database, you can make the user's auth key a key-value pair in the user's account so that you can easily find the auth data (displayName, photoURL, etc.) associated with this user.

With one database for Auth, another for binary file Storage, and a third database for everything else, you have a lot of keys to keep track of.

For big data projects, Firebase Realtime Database has additional limitations. The data can only nest 32 layers deep. Scaling up requires sharding. If your client is doing big data, or delusionally thinks that his 5000 records is big data, you'll have some arguing to do to persuade your client not to use SQL on a server.

Why Cloud Firestore?

Why? The queries! With Cloud Firestore I can now query my dogs array, requesting the record with the name equal to China. Firebase returns only the object I want.

Cloud Firestore can sort and filter data.

Cloud Firestore can handle subcollections within documents. You can request an document that contains subcollections of documents, and just get the document, without it's subcollections. I.e., shallow queries. You can even delete a document that contains subcollections of documents, and keep the subcollections.

Cloud Firestore also scales better than Firebase Realtime Database. The security is better, and there are other new features and improvements.

Inject Dependencies

First, you need to add Cloud Firestore to your project. In your index.html file after you link to the Firebase CDN, link to the Cloud Firestore CDN:

<script src="https://www.gstatic.com/firebasejs/4.5.0/firebase.js"></script>
<script src="https://www.gstatic.com/firebasejs/4.5.0/firebase-firestore.js"></script>

Or download the Node module and link to it:

npm install [email protected].5.0 --save

If you're using the Firebase SDK on a Node server you'll also need to add a dependency:

const firebase = require("firebase");
// Required for side-effects
require("firebase/firestore");

Also in index.html you'll need to initialize the app:

firebase.initializeApp({
  apiKey: '### FIREBASE API KEY ###',
  authDomain: '### FIREBASE AUTH DOMAIN ###',
  projectId: '### CLOUD FIRESTORE PROJECT ID ###'
});

If you're also using Firebase Realtime Database, Storage, and Cloud Messaging you'll have more stuff:

firebase.initializeApp({
  apiKey: '### FIREBASE API KEY ###',
  authDomain: '### FIREBASE AUTH DOMAIN ###',
  databaseURL: "https://###.firebaseio.com",
  messagingSenderId: "###",
  projectId: '### CLOUD FIRESTORE PROJECT ID ###',
  storageBucket: "###.appspot.com"
});

And, finally, make a reference to Cloud Firestore in your controller:

var db = firebase.firestore();

Migrating Your Data

Next, you'll want to migrate your data from Firebase Realtime Database to Cloud Firestore. This is easy.

return firebase.database().ref('dogs').once('value') // get a snapshot of the user's data
.then(function(snapshot) { // then execute a promise on the snapshot
  snapshot.forEach(function(childSnapshot) { // iterate through the user's data
    let childData = childSnapshot.val(); // this is the user's data
    db.collection('dogs').doc(childData.dog).set(childData); // each dog is written to Cloud Firestore
  })
});

Don't do this:

return firebase.database().ref('dogs').once('value') // get a snapshot of the user's data
.then(function(snapshot) { // then execute a promise on the snapshot
    db.collection('dogs').set(snapshot); // copy the array to Cloud Firestore
});

The latter will copy the Firebase Realtime Database keys. It also won't work because you can't upload collections to Cloud Firestore, you can only upload documents.

In the former example, the forEach loop iterates through each record and uploads it as a document to Cloud Firestore. The collection is created automatically and named dogs. This also removes the Firebase Realtime Database keys and replaces them with Cloud Firestore keys.

The return stops any code executing after this command. If you want to migrate many arrays, then use return only on the last command:

firebase.database().ref('dogs').once('value') // get a snapshot of the user's data
.then(function(snapshot) { // then execute a promise on the snapshot
  snapshot.forEach(function(childSnapshot) { // iterate through the user's data
    let childData = childSnapshot.val(); // this is the user's data
    db.collection('dogs').doc(childData.dog).set(childData); // each dog is written to Cloud Firestore
  })
});

firebase.database().ref('cats').once('value') // get a snapshot of the user's data
.then(function(snapshot) { // then execute a promise on the snapshot
  snapshot.forEach(function(childSnapshot) { // iterate through the user's data
    let childData = childSnapshot.val(); // this is the user's data
    db.collection('cats').doc(childData.cat).set(childData); // each cat is written to Cloud Firestore
  })
});

return firebase.database().ref('cetaceans').once('value') // get a snapshot of the user's data
.then(function(snapshot) { // then execute a promise on the snapshot
  snapshot.forEach(function(childSnapshot) { // iterate through the user's data
    let childData = childSnapshot.val(); // this is the user's data
    db.collection('cetaceans').doc(childData.cetacean).set(childData); // each whale and dolphin is written to Cloud Firestore
  })
});

Nesting Data in Collections and Documents

Firebase Realtime Database allows you to have arrays in arrays, objects in objects, arrays in objects, or objects in arrays. Cloud Firebase only allows documents (objects) in collections (arrays), and collections in documents. In other words, Cloud Firebase data is always structured collection - document - collection - document, etc.

Perhaps you want to copy a nested array to a subcollection:

return firebase.database().ref('dogs').child('girlfriends').once('value') // get a snapshot of the user's data
.then(function(snapshot) { // then execute a promise on the snapshot
  snapshot.forEach(function(childSnapshot) { // iterate through the user's data
    let childData = childSnapshot.val(); // this is the user's data
    db.collection('dogs').doc(childData.word).set(childData); // write the data to Cloud Firestore
    db.collection('dogs').doc('dogs').collection('girlfriends').doc(childData.dog).set(childData);

  })
});

Here we are getting the array girlfriends from the array dogs, iterating through the array with a forEach loop, and writing each record to a collection girlfriends in a document dogs in a collection dogs. I named both the top collection and the top document dogs. You could use different names.

Updating Code

Now we'll get started updating our code.

Updating References

We've already updated one line of code. We updated our Firebase Realtime Database reference:

let ref = firebase.database().ref();

to Cloud Firestore:

let db = firebase.firestore();

You can leave the Firebase Realtime Database reference for the moment, and then comment it out or remove it when we're finished.

I have one other Firebase Realtime Database reference, to my users array:

let users = firebase.database().ref('users');

We'll update that to:

let usersFS = firebase.firestore().collection('users');

We'll use different names so that we can run both databases together, until we've finished our migration.

Updating Queries

Now we can start updating our queries. In my controller, my first firebase.database().ref query is:

firebase.database().ref('userLoginEvent').update({'user': user.uid})

For Cloud Firestore we instead use:

db.collection('userLoginEvent').doc('HUSEj7dPh8xsOw32feQY').update({'user': user.uid});

The code is almost identical except that Cloud Firestore requires specifying a document in a collection. Here I reference the document's key because this command always writes to the same location in the database.

Next, I have:

firebase.database().ref('users').child($scope.userAccountKey).update(englishWords);

We'll update that to:

db.collection('users').doc($scope.userAccountKey).update(englishWords);  // this isn't working

And Who in Marketing Named It Cloud FireStore?

That name is too long! Looking up domain names, I see that fire.me is still available. I wonder why no one in marketing suggested that short, memorable domain name?




So I wrote an entire blog post all about this very question, and I recommend you check it out (or the official documentation) for a more complete answer.

But if you want the quick(-ish) summary, here it is:

Better querying and more structured data -- While the Realtime Database is just a giant JSON tree, Cloud Firestore is a little more structured. All your data consists of documents (which are basically key-value stores) and collections (which are collections of documents). Documents will also frequently point to subcollections, which contain other documents, which themselves can contain other documents, and so on.

This structured data helps you out in two ways. First, all queries are shallow, meaning that you can request a document without grabbing all the data underneath. This means you can keep your data stored hierarchically in a way that makes more sense to you without having to worry about keeping your database shallow. Second, you have more powerful queries. For instance, you can now query across multiple fields without having to create those "combo" fields that combine (and denormalize) data from other parts of your database. In some cases, Cloud Firestore will just run those queries directly, and in other cases, it will automatically create and maintain indexes for you.

Designed to Scale -- Cloud Firestore will be able to scale better than the Realtime Database. It's important to note that your queries scale to the size of your result set, not your data set. So searching will remain fast no matter how large your data set might become.

Easier manual fetching of data -- Like the Realtime Database, you can set up listeners in Cloud Firestore to stream in changes in real-time. But if you don't want that kind of behavior, and just want a simple "fetch my data" call, Cloud Firestore has that as well, and it's built in as a primary use case. (They're much better than the once calls in Realtime Database-land)

Multi region support -- This basically means more reliability, as your data is shared across multiple data centers at once. But you still have strong consistency, meaning you can always make a query and be assured that you're getting the latest version of your data.

Different pricing model -- While the Realtime Database primarily charges based on storage or network bandwidth, Cloud Firestore primarily charges based on the number of operations you perform. Will this be better, or worse? It depends on your app.

For powering a news app, turn-based multiplayer game, or something like your own version of , Cloud Firestore will probably look pretty favorable from a pricing standpoint. For something like a real-time group drawing app where you're sending across multiple updates a second to multiple people, it probably will be more expensive than the Realtime Database.

Why you still might want the to use the Realtime Database -- It comes down to a few reasons. 1) That whole "it'll probably be cheaper for apps that make lots of frequent updates" thing I mentioned previously, 2) It's been around for a long time and has been battle tested by thousands of apps (Cloud Firestore is still in beta), 3) It's got better latency and when you need something with reliably low latency for a real-timey feel, the Realtime Database might work better.

For most new apps, we recommend you check out Cloud Firestore. But if you have an app that's already on the Realtime Database, I don't really recommend switching just for the sake of switching, unless you have a compelling reason to do so.

Hope that helps!