I want to make an online QuizGame using Android Studio and Firebase.
First step will be a game mode for one Player where he gets Questions from the server. The code itself is not a big problem but I have a question about the reads/pricing of Firestore.
The gameplay will look like this: One Round, 5 questions. I want to make a Database looking like this:
Project: Category(Collection) -> generatedID(Document) -> custom Object (My custom Object has an Arraylist of Question, Correct AnswerA, AnswerB, C and D).
My general question is, lets say I am looking for an ID. I have for example 50 IDs in my Category Collection. If I start a query it will check every entry if the saved ID == my searched ID. Will that be a total of 50 reads or only one?
Firestore pricing is based on document reads, writes and deletes. If you run a query, you will be charged for any documents returned by that query, not the total number of documents in the collection. You can avoid un-necessary cost by the use of cursors and pagination, if you need to return large datasets. If you are only searching for a single ID, then it is likely that'll only return one document and, therefore, it'll only cost you for one document read.
If your query returns no results, you will be charged for one document read.
You can get more details from the Cloud Firestore pricing page
Related
As there is no functionality of foreign Key in Firestore like that of MYSQL, so I am not able to replicate one of my important functionality that is to update a file in one place and it will reflect in every place. Also, Firebase has no functionality to update all the document's specific filed at once.
There are already these kinds of questions but I could not get my solution. Suppose I have a million documents containing a filed which is the density of a material. Later on, I found that my density value was wrong so how to update that value in all documents efficiently. Also, I do not want to use server/admin SDK.
If you need to change the contents of 1 million documents, then you will need to query for those 1 million documents, iterate the results, then update each of those 1 million documents individually.
There is no equivalent of a sql "update where" statement that updates multiple documents in one query. It requires one update per document.
If don't want to use the Admin SDK, then the option that you have is to update the value of your densityMaterial property on the client, which might not be the best solution. However, if you can divide the update operation in smaller chunks, you might succeed.
If you are using a POJO class to map each document, then you might be interested in my answer from the following post:
How to update one field from all documents using POJO in Firestore?
And if you are not using a POJO class, please check my answer from the following post:
Firestore firebase Android search and update query
Regarding the cost, you'll be billed with one write operation for every document that is updated. If all 1 MIL documents will be updated, then you'll be billed with 1 MIL write operations.
Edit:
Suppose I have a million documents containing a filed which is the density of a material. Later on, I found that my density value was wrong so how to update that value in all documents efficiently.
If all of those 1 MIL documents contain a property called densityMaterial, that holds the exact same value, it doesn't make any sense to store that property within each document. You can create a single document that contains that particular value, and in each and every document of those 1 MIL, simply add only a reference to that document. A DocumentReference is a supported data-type. Now, if you need to change that value, it will incur only a single document write.
However, if you have different values for the densityMaterial property and all of them are wrong, then you don't have a problem with the database, you have a problem with the mechanism/people that are adding data. It's not a matter of a database problem if you have added 1 MIL incorrect documents.
Why not chose MySQL?
MySQL cannot scale in the way Cloud Firestore does. Firestore simply scales massively.
Can I avoid this problem anyhow?
Yes, you can buy using a single document for such details.
I am building a social app that lets users add posts based on the country code. For main feed, I will fetch posts of every country posts based on timestamp. For example, if you are in Turkey, only posts within Turkey will show up in your feed. There is no follower/ following system.
Should I store all posts in one posts collection with the country code field? Or it is more flexible to group them as posts/countryCode/posts. I just don't know if firestore is powerful enough to query all posts for specific country code and timestamp.
What is the best approach for flexibility and pricing?
For only what you're describing here, it actually doesn't matter at all what you choose.
Pricing is based on the number of documents read in a query. That's not going to change in either case.
If all you want to do is query by country code, it doesn't matter if you put everything in one collection, or use subcollections with a collection group query. As long as the country code is a field in the document, either way, you will be able to filter for only that code.
Choose whatever one you are more comfortable with.
My idea is to create a like&unlike system for posts (a user can like and unlike a post) and to show a list of users in a fragment, ordered this way: the top user is the one for which there are the most numerous likes.
In my Firebase Firestore database:
I have a collection of posts. Each document (which is a post) contains the ID of the user that created it, and a counter of likes (I call it "A").
I have another collection, of users. Each document (which is a user) contains a counter (I call it "B") that counts for the number of likes, all posts combined.
For the moment, I use "B" to order the users in the list of users I've described above. I use "B" this way: return FirebaseFirestore.getInstance().collection("users").orderBy("likes", Query.Direction.DESCENDING);.
However, due to some technical facts in relation to Firebase Security Rules, and to simplify the database structure, I would want to only use "A", and remove "B". More precisely, I would want to get all the users, and order them according to "A". However, the counter "A" is defined in the documents of the collection of posts, whereas the counter "B" was defined in the documents of the collection of users: that makes it easier to use.
So my question is: for each user, I would have to get all their posts, then sum up their counter "A", then get all the users, then order them according to this sum. However, I would want to know: is it possible to do this using Firebase Firestore Android API? (something like the instruction given before) In others words: How to order documents from a collection, according to the field of documents of another collection? But note that in fact it's more difficult, since I must sum up the counter "A" of each post created by the user.
What you're trying to do is essentially a "join" type operation, which is not supported by Firestore. A Firestore query can only consider documents in a single collection at a time. If you have data from two collections to use for the purpose of generating query results, you will have at least two queries to perform.
The only real alternative you have is to introduce a third collection with data already merged from the other two collections that supports the query you want to make. This is common in NoSQL type databases, and is called "denormalization".
I have data structure like this:
Employees (Collection) > {EmployeeID} (Documents) > Chat (Collection) > {ChatId} (Documents).
In chat collection each document having 3 fields. 1. senderName, 2. sendTimestamp, 3. messageText.
I want to delete chats which are older than 7 days (from today).
I think it might be possible through cloud function but I am really basic user and don't know much about cloud functions. Please note that I don't want to make it automatically (cron job). I will do it manually on daily basis or whenever I wish.
I really searched a lot for this but its really hard. Please help me.
A big part of this task involves querying a sub collection. You can read more about this idea here: Firestore query subcollections
There are basically two options at the time of writing this:
Query the entire top level collection (Employees) something like db.collection('Employees').get(). Then you would have to loop through each employ object querying for their sub collection (Chat) based on their date range. Firestore query by date range for more reading on querying by a date in firestore. This could result in a large amount of reads depending on the number of Employee documents, but is the "easiest" approach in terms of not having to make changes to your data models/application.
Restructure your data to make the sub collection Chat a top level collection. Then you can do a query on this top level collection by the date. Less reads, but may not be as feasible depending on if this app is in production/willingness to make code changes.
A Function would definitely be able to accomplish this task either way you decide to approach it. One thing to note is that a Function executes using the Admin SDK, meaning it can basically ignore security rules set up on your Firestore.
I am learning my basics for Firestore and trying to build an app which allows user1 to share a document with user2/3/4 etc.
For billing purposes, every query which results in a document read counts towards the cost. So, I do not want to follow the approach of adding the user2/3/4 etc emails to a 'sharedWith' variable to type: array or map type structure as I believe every user will then have to scan the entire collection and pick the documents where their email appears.
Is there any other approach to this where user1 can programmatically give access to user2/3/4 of one specific document?
For billing purposes, every query which results in a document read counts towards the cost.
That's correct and according to the official documentation regarding Cloud Firestore billing:
There is a minimum charge of one document read for each query that you perform, even if the query returns no results.
So you're also charged with one document read, even if your query does not return any results.
I believe every user will then have to scan the entire collection and pick the documents where there email appears.
That's also correct. So let's assume the email address that you are looking for exist in a document that is appart of 10k collection of documents. So if you query the database only for that particular document, you'll be charged with only one document read and not for those 10k. So you are charged according to the number of items you get back and not to the number of items your request them from. And this is available for the first request, when you get the data from the Firebase servers. If in the meanwhile nothing has changed, second time you get the data from the cache since Firestore has the offline persistence enabled by default. Which means you aren't charged for any other document reads.
Is there any other approach to this where user1 can programatically give access to user2/3/4 of one specific document?
Without writing the data to database, there is not. So you should add the ids or email addresses to the desired documents and perfom a query according to it.