When we delete a child value in Firebase Realtime Database, it counts as an exclusion, correct?
But when we delete a node with several children, does it count as just an exclusion too? or is each child that belongs to the node counted as exclusion?
I'll explain it better: supposing it has this structure in firebase:
Each firebase plan has an exclusion limit.
1) How many exclusions are registered if I do this below? I believe that 3 exclusions, right?
referenceOne = (...).child("1");
referenceOne.removeValue();
referenceTwo = (...).child("2");
referenceTwo.removeValue();
referenceThree = (...).child("3");
referenceThree.removeValue();
2) Now, how many exclusions are registered if I do this?
reference = (...).child("users");
reference.removeValue();
3 exclusions or 1 exclusion?
You're mixing up Firebase database products. The documentation you linked to is for Firestore, but the code you're showing is working with Realtime Database. They have very different billing structures. What you linked to has no relation to what you're actually doing.
Realtime Database doesn't charge you for individual writes like Firestore does. If you want to know how Realtime Database bills you, read its documentation. You can delete as much data as you want without getting billed. You are billed primarily for data downloaded and data stored.
Related
I have a firestore collection with a bunch of documents, each with plenty subfields. On a web page I need a list of a specific subfields from each document.
Currently I load the the entire database when you load the page and then loop through and get the wanted values. This uses way to many reads to get very little data.
Is there a way to solve this e.g. a autogenerated a collection that contains field from other collection in an array or something.
Many thanks in advance
Auto-creating such a subcollection with just the fields you need is a great way to reduce the bandwidth needed to load the data.
There is nothing built into Firestore to create those derived documents, but it's fairly easy to build something using Cloud Functions. Create a function that responds to a Firestore onWrite trigger, and write the subset of the data to its destination there. It's common to have a separate Cloud Function for each such use-case, and I regularly see projects with 100+ such functions.
I expect we'll also start seeing Firebase Extensions for this type of thing, but right now no-one seems to have built one.
I want to store the comma separated ids on a child node & how can I filter data as in sql we can use IN clause to fetch data any possibility in firebase to perform this kind of operation in firebase database.
Please suggest any possible solution for this.
Firebase Realtime Database doesn't have the equivalent of SQLs IN clause. It also doesn't have a way to find a substring in a value. So the data model you are looking to use, doesn't allow the use-case you want. As usual with NoSQL databases, the solution is to pick a data model that does allow your use-case..
The most likely cause I know for the structure you describe is to associate the child node with a bunch of categories. If that is your case, read my answer here for a proper data structure: Firebase query if child of child contains a value
This is one of the cases where the new Cloud Firestore database offers better querying support, since it recently added a feature to efficiently test if an array contains a certain value (video). If you're only just getting started with your project, you might want to check if Firestore is a better fit for your use-cases.
How does one select the last n items in a collection in firestore? I'm considering migrating a new project from the real time database to firestore. In the realtime database, I used the below code:
ref.orderByKey().limitToLast(n);
I've reviewed the docs at https://cloud.google.com/firestore/docs/query-data/order-limit-data, and they don't appear to mention how to achieve this in firestore. I suppose I could add a timestamp field to every element of the collection and then order by descending timestamp, but I think there should be an easier way to accomplish this.
In the Firebase Realtime Database there was the concept of a push ID, which was a key that was automatically chronologically ordered. This made ordering nodes chronologically in a query as easy as you've shown.
In Cloud Firestore there is no built-in metadata for when a document was added, or when it was last updated. If you want to build queried based on such metadata, you will have to set the corresponding properties on the documents yourself.
I'm using Meteor JS for a project so inherently I'm using MongoDB. I'm storing a user's check in and out actions. I'm currently storing them as individual docs in the collection. Each action contains 3 fields; in or out, time of action and userid. Is the best way to go though? Should I just have one doc per members and then store each action in an array? Is there another way? I anticipate several hundred members, but hopefully several thousands of members in the future. Thanks.
From experience, I can say that storing records instead of arrays is a better choice in the long run.
As far as Meteor is concerned, its reactivity handles collection records, but not individual fields in arrays. In other words, if one element gets added to the checkins array of a user object, the entire user object needs to be synchronized with the clients. If you store records instead, only the newly added record will be sent by the publication.
As far as MongoDB is concerned, there is a document size limit of 16MB. Not sure how frequent your checkins and checkouts are, but if you store them in an array, you might run into that limitation at some point.
Records are also easier to access than arrays.
For more details, see MongoDB data modeling and Database modeling in Bulletproof Meteor.
I am creating a mock app with user creation/auth/friend in a node js learning exercise. Having spent my time mostly at the front end of things, I am a n00b as far as DBs are concerned. I want to create a user database where I want to keep track of user profiles and their connections/friends.
Primary objective is to load/store users connections in the database.
Fetch this information and give it to the user most efficiently in least number of queries.
I'd really appreciate some help with a DB structure I should be using that can accomplish this. I am using mongodb and node.
Off the top of my head: I can store the user's connections in an object in the "connections" field. But this will involve making a lot of queries to fetch connections' details like their "about me" information - which I can also store in the same object as well.
Confused. Would really appreciate some pointers.
Take a look at the Mongoose ORM. It has a populate method that grabs foreign documents. Lots of other great stuff too.
You could say
Users.find({}).populate('connections').exec(function(err,users) { ... });
Before popualte the users' array of connections was an array of IDs, after, its an array of user documents.