I need to know to link how to link two documents of different collection in firebase.
The method to link them.
Related
I am making a type of social media app where there is a list of conversations available for all users to see. I have implemented a feature for a blue circle to be found on unread messages:
however my implementation seems like a bad foundation to scale up on. I am looking to a better solution, if possible. The current method is as follows:
1)This app is built around a few special users, called Stingray, who can start chats.
2)the chats live in a collection called StingrayChats. One document holds a list of Chat items. There is one chat document for each stingray. All chats in a collection a queried, and combined into a single chats list on the frontend.
Next, there is a separate collection called Viewers. Similarly, there is one viewer document for each stingray. Each viewer document contains a list of ChatViewer objects, which contains:
-A string, chatId
-A list of strings id's of viewers who have viewed the chat
In the frontend, once again all viewers documents are compiled into a single list, and if a chat's ChatViewer object contains an array with the user's id, this means the user has seen the chat, and the circle will no longer appear.
the big problem with this at the moment is that it costs a large amount of unnecessary reads, in that when the array is updated a user will read it, which does not actually reflect anything in the ui if the userId is not the current user.
Is there any better implementation for something like this? To reiterate, it would need to:
Reset everytime a new message was sent in the chat
Keep track of what users have seen it
Change when a user clicks on it, if applicable
Thanks!
I have a question. I have an app that allows users to save posts by clicking an icon. Posts are saved in Firebase inside a collection called "saved", this collection is inside another collection called "posts". This is a saved sample post:
Here is an example of an unsaved post:
The question is, how do I retrieve only the saved posts?
Any sample code you write can help me, or even suggest an idea.
you can achieve your goal by multiple ways, but I think since you are trying to get all collections in your database that is names saved, consider trying Collection Group it would help get all documents inside any saved collection in your database, for more information you can check:
https://firebase.google.com/docs/firestore/query-data/queries#collection-group-query
I have an object stored in the Firestore database. Among other keys, it has a userId of the user who created it. I now want to store an email address, which is a sensitive piece of info, in the object. However, I only want this email address to be retrieved by the logged in user whose userId is equal to the userId of the object. Is it possible to restrict this using Firebase rules? Or will I need to store that email address in a /private collection under the Firebase object, apply restrictive firebase rules, and then retrieve it using my server?
TL;DR: Firestore document reads are all or nothing. Meaning, you can't retrieve a partial object from Firestore. So there is no feature at rule level that will give you granularity to restrict access to a specific field. Best approach is to create a subcollection with the sensitive fields and apply rules to it.
Taken from the documentation:
Reads in Cloud Firestore are performed at the document level. You either retrieve the full document, or you retrieve nothing. There is no way to retrieve a partial document. It is impossible using security rules alone to prevent users from reading specific fields within a document.
We solved this in two very similar approaches:
As you suggested, you can move your fields to a /private collection and apply rules there. However, this approach caused some issues for us because the /private collection is completely dettached from the original doc. Solving references implied multiple queries and extra calls to FS.
The second option -which is what the Documentation suggests also, and IMHO a bit better- is to use a subcollection. Which is pretty much the same as a collection but it keeps a hierarchical relationship with the parent coll.
From the same docs:
If there are certain fields within a document that you want to keep hidden from some users, the best way would be to put them in a separate document. For instance, you might consider creating a document in a private subcollection
NOTE:
Those Docs also include a good step-by-step on how to create this kind of structure on FS, how to apply rules to them, and how to consume the collections in various languages
How to structure a Social Network database structure like for example twitter where we can follow a users and get all their tweets in our timeline, i have already checked this Firestore - how to structure a feed and follow system
but the solutions in the post look flawed.
Firestore is different where it requires redundant data to access data efficiently, but suppose i am following 1000 people and if i need to get the posts of all those users by querying data for each 15 users i am following and using limit(10) method then orderBy(timeStamp) there may be unread posts between Queries, because we are getting the post using the last post timeStamp , how to structure the data for a social media app in Firestore
When modeling a use-case on a NoSQL database, you tend to optimize for the features of your application, and for frequent read-operations.
So in a social media application your main feature may be that the user sees the recent posts of everyone they follow. To optimize this operation for frequent reads, you'll want to store the posts that the each user should see in a document for that user. So when compared to Twitter, you'd pretty much have a document containing the twitter feed for each user. Or if there's too much data for a single document, you might want to put that in a collection. I often explain this as modeling the screens of your app in the database.
This is very different from the typical data model in a relational database, so it's normal that it takes time to get used to. For a good introduction, I recommend:
Reading NoSQL data modeling.
Watching Firebase for SQL developers, even though it's for the Realtime Database, it explains how to map common SQL concepts to Firebase's NoSQL model.
Watching Getting to know Cloud Firestore
To develop a social media app like Twitter. The Firestore queries are not enough.
Twitter generates a personalized timeline for every user.
This is where the cloud functions come into the picture.
You need a cloud function that monitors for new posts and copies them in their following user's timelines.
You don't need to copy the entire tweet data. You can just copy the tweet id and other fields which require ordering, like timestamp.
So when I query my timeline, I will get all the tweet ids.
Then I can just load the original tweet when the user is about to scroll.
Because the likes and dislikes should affect the original tweet.
Type of App to give context: An app that enables wedding bands to create a profile. Part of this profile will be to enter different dates with locations (Events)and return them in a list view. I have a Firestore collection called userData. The collection is made up of documents IDs(Firebase User ids) generated during sign in. These documents contain fields, mainly Strings and arraysfor things like a header image.I'm thinking of creating a class called Events with member variables date and venue. I'm wondering how I should structure Firestore to allow the Events be queried and returned in a listView. I've looked at sub collections where the UserData would be a parent but I'm not sure is this possible? Or maybe creating a collection at the root called Events but not sure how'd I'd connect the different bands to their Events. Here is a screen shot of Firestore. Each document is a band.
You can either:
Use a new top-level collection to store all events, with a field for the id of the band to help with querying for events for only that bad.
Use a subcollection under each band for their events.
It's totally up to you to choose. It will depend on the kinds of queries you want to make. Note that if you go with #2, you will not be able to query for events across bands (at least not until Firestore supports collection group queries which it does not today).