I have a small database in Firebase realtime database which contains posts added by users. Everytime I open the console, each and every post is in the correct position.
I'm trying to migrate to Cloud Firestore. I've created a script to copy every post objects from Firebase realtime database to Cloud Firestore and works fine.
The problem is when I switch the tab to Firestore, the posts are not ordered anymore and I find hard time to find a post.
How can I order the posts in the exact same way that were in Firebase and also in the ListView?
Strange Firestore console situation
It is not strange, is the normal sorting scheme provided (by default) in Firebase console.
Unlike the Fireabse realtime database ids, Cloud Firestore ids are actually purely random. There's no time component included. That is why (by default) there is no order. However, as Frank van Puffelen mentioned in his comment:
The Cloud Firestore console support sorting/filtering of the documents on any field (since June 2018), by clicking the "filter" icon above the document list.
Beside that, if know the id of a document, just simply CTRL + F in your browser and you'll be able to find the desired document very easy. In my opinion, this sorting scheme makes it relatively intuitive to find the document you might be looking for.
If you want to order your elements in your ListView, you should add those requirements into queries. The order in your query is not related with order you see in the dashboard.
Those ids are required so an app like yours can work perfectly on a big scale. At a big scale, it doesn't matter what order the documents appear in the console because the console is useless for viewing large amounts of documents.
A solution for ordering your posts in the ListView, would be to order your posts according to a timestamp property.
For Android, here you can find how to add the date using a model class or FieldValue.serverTimestamp().
Related
What is that query builder which is shown on the Firebase Firestore page, what's its use case and how does it benefit my project?
From the documentation, I get that it's used to query collections and sub-collections in that actual Firestore database.
But does this used just for visualizing the queries from it? or does it prepare those types of queries to be ready when requesting them so it will cause some performance and speed of requesting improvements?
and when should I use it, and when I shouldn't?
The new query building in the Firestore console is just a visual way to build a query that then determines what data the console shows. I find it most helpful to limit the amount of data the console shows, and to see if a query is going to be possible before I translate it in to code.
Aside from that, the query build shows the resulting documents in a tabular view (rather than the panel view that already existed), which makes it possible to compare documents at a glance and fits more data in less space.
I'm currently developing a Flutter web application using Firestore for data persistence. The app is not live in production, so I'm the only one accessing this backend. There is only one collection that holds a single document, with many nested fields (6 levels deep). My understanding from looking at https://firebase.google.com/docs/firestore/pricing, is that reads are counted per doc, so every time I reload my app it should count as one read, yet in the last 4 hours since I started working today I already hit 1.7K reads (as reported in the usage tab). I know I haven't reloaded the app that many times, and there's also no hidden loop that calls the collection multiple times.
This is the Flutter code that calls Firestore:
final sourceRef=FirebaseFirestore.instance.collection("source");
var data=await sourceRef.doc("stats").get();
What am I missing please?
According to Firebase pricing, writes are defined as:
You are charged for each document read, write, and delete that you perform with Cloud Firestore.
Charges for writes and deletes are straightforward. For writes, each set or update operation counts as a single write.
Meaning that one document created is one write. If the same document is updated later, then Firebase counts it as one more write.
Here is a more detailed table that you can use for billing, and an example.
It is recommended to view individual product usage in the "Usage" tab for many products in the Firebase console, as this can narrow the product that is causing the elevated usage that you are seeing.
I would highly recommend adding write and view logs to your application; that way, you can monitor how many writes and reads you have.
I have just published an app that uses Firestore as a backend.
I want to change how the data is structured;
for example if some documents are stored in subcollections like 'PostsCollection/userId/SubcolletionPosts/postIdDocument' I want to move all this last postIdDocument inside the first collection 'PostsCollection'.
Obviously doing so would prevent users of the previous app version from writing and reading the right collection and all data would be lost.
Since I don't know how to approach this issue, I want to ask you what is the best approach that also big companies use when changing the data structure of their projects.
So the approach I have used is document versioning. There is an explanation here.
You basically version your documents so when you app reads them, it knows how to update those documents to get them to the desired version. So in your case, you would have no version, and need to get to version 1, which means read the sub-collections to the top collection and remove the sub collection before working with the document.
Yes it is more work, but allows an iterative approach to document changes. And sometimes, a script is written to update to the desired state and new code is deployed 😛. Which usually happens when someone wants it done yesterday. Which with many documents can have it's own issues.
I am trying to build a mobile app which has a NewsBulletin feature using a NoSQL Cloud Firestore. I am trying to get the unique post view by keeping the user's uid into an array called "views" and count it by getting the length of the array. Is this recommendable or are there other better solution for this? Thank you
Currently this is the structure of my database:
News(Collection)
-DummyNews1(Document)
-newsTitle
-posterName
-bodyMessage
-timeCreated
-views(array)
-dummyuid1
-dummyuid2
I like your solution as it is easy to implement. You don't actually have to manually check for duplicate uids, as firestore has a built in feature that does that for you.
Here is an example:
FirebaseFirestore.instance.collection('news').doc('documentId').update({
'views': FieldValue.arrayUnion([viewerUid]),
});
FieldValue.arrayUnion will check if the contents exists in the database, and only when it does not will add the content.
Now, although I am a fan of you solution, and I do use this method for like type of feature in my own published apps, there are some limitations that you should be aware in case your app becomes super popular.
Maximum document size in firestore is 1MiB. Since firebase auth's uid is 28 characters long, that would be about 37,400 views maximum to be stored in a document ignoring other fields.
But if this is a new application, I would not worry too much about this limit. Besides, once you get close to this limit, you should have more than enough resources to pivot to another method that scales.
I'm setting up a Firestore database and am playing around with structuring it. Is there a way to populate and change it quickly without having to add/change fields manually every single time?
Two example things I am looking to do are:
1) Populate collections with documents that have predetermined fields. Currently I have to add the fields manually every single time.
2) Edit the fields en masse for all documents within a collection (e.g. change the name of a field, delete a field entirely, add a new field)
The Firebase console doesn't seem to provide these tools, would my best bet be to write a separate app specifically for this purpose?
Since such bulk uploads and bulk edits are not part of the console, you'll have to build something yourself indeed.
A good place to start would be the Cloud Firestore API, which allows adding and updating documents in the database.