I'm using flutter with firebase, when i register an account into firebase how do i get a .collection('userData').document(uid)
.collection('bio') already make with that account, what i want to do is, when i create the account, some data is already in the 'bio' documents for me in the cloud Firestore such as:
name: ""
age: ""
date: ""
height: ""
and so on, then all i have to do is fill out those fields to show on my app, i'm doing this for all the students in my school, and i can do it manually but that will take way to long since its way over 5,000 students, or is it even possible to copy the .collection with one array of data such as the one above and paste in into each user 'bio' document and go from there with each of them instead of having to keep adding fields for each one.
Related
I have an app where people can sign up for user accounts. They can use their Google account or sign up using email/password. I am storing the user's displayName in Firestore so I can reference it throughout the app as their username.
However, there is a problem:
Let's say "John Doe" signs up for a user account on my app and he uses his Google account named johndoe#gmail.com. His Google account's display name is also "John Doe". However, a few days later, another with the same name "John Doe" signs up for a user account, and although his Google account email may be different (let's say, johndoe2#gmail.com), his display name is still the same. Now, I have 2 users in my app with the same display name "John Doe". This causes an issue when I am trying to create user name routes such as: https://myapp.com/JohnDoe and handling user profile lookups.
What is the recommended way to allow users to use their Google accounts if there are other users that may have the same display names? The catch is I don't want to store UIDs in the URL as I want it to be clean with just the displayName.
The catch is I don't want to store UIDs in the URL as I want it to be clean with just the displayName.
It might be clean, as long as the number of characters within the displayName is reasonable. In your example, "John Doe", contains only 8 characters, including the whitespace character between the names, which is fine. But I've seen so many examples of names that are larger than 28, the number of characters that exist in a UID. Since the displayName property is set within the Google account and it can be changed only by the user, you're having three solutions left.
The first one would be to create your own mechanism for setting specific user names into your application. These user names can be set especially by the users. It can be the same as the names in the Google account or not. However, when someone chooses "JohnDoe" and a second user wants to set the same user name, it won't be possible, since a "JohnDoe" is already present. So before setting a new user name, you should always check if that one is already present. You can do that because it's something that you control. When using Firestore, this can be simply done by using:
db.collection("users").whereEqualTo("userName", "JohnDoe");
Or when using the Realtime Database:
db.child("users").orderByChild("userName").equalTo("JohnDoe");
Now, the first "John Doe" will have a profile that looks like this:
https://myapp.com/JohnDoe
While the second one might have something like this:
https://myapp.com/John_Doe
See the underscore? This kind of mechanism is very widely used. Facebook, Instagram, Twitter, eBay, Reddit, and many more do that:
https://www.facebook.com/JohnDoe/
https://www.instagram.com/JohnDoe/
https://twitter.com/JohnDoe/
https://www.ebay.com/usr/JohnDoe/
https://www.reddit.com/user/JohnDoe/
The second one would be to ignore the user names and use only the UIDs that come from the authentication process. Case in which, your URL will look like this:
https://myapp.com/TwentyEightCharactersLong
That's not unusual, since other big apps use it:
https://www.imdb.com/user/$userId/
The third one would be to create a combination between the UID and the user name. The best example would be Stackoverflow:
https://stackoverflow.com/users/$userId/$userName/
// ^ ^
Or LinkedIn:
https://www.linkedin.com/in/$userName-$userId/
// ^ ^
Doesn't matter which solution will you apply, you'll always have unique URLs. But it's up to you to choose which one of these solutions seems more clear to you.
It's quite common to see URLs suffixed with some random number or combination of alphanumeric characters like john-doe-1 and so on. That being said you would have to implement logic for this yourself maybe using Firebase Auth Triggers for Cloud Functions which will run whenever a new user is created and you can add an URL for their name.
You could also add some random string like /users/john-doe-qwerty and maybe add a paid feature that allows user to set their own URLs (if applicable for your application) i.e. vanity URLs.
I recently had this issue too, after playing around with 2 separate Google Play accounts, I found that the user.UserId is static and unique, and while the user.DisplayName can be changed, display names are unique.
Therefore, you should be safe storing data under UserId and then grabbing their current display name on login. Alternatively, to match your wants, you can save the data under the display name but you might want to track their user identification code in case they change their display name (if you wish to accommodate that)
I have a real-time database on firebase which consists of ListFields. Among these fields, one field, participants is a list of strings and two usernames. I want to make a query to firebase database such that it will return the documents in which a particular username is present in the participants list.
The structure of my document is as follows :
I want to make a query such that Firebase returns all the documents in which the participants list consists aniruddh. I am using Flutter with the flutterfire plugins.
Your current data structure makes it easy to find the participants for a conversation. It does however not make it easy to find the conversations for a user.
One alternative data structure that makes this easier is to store the participants in this format:
imgUrls: {},
participants: {
"aniruddh": true,
"trubluvin": true
}
Now you can technically query for the the conversations of a user with something like:
db.child("conversations").orderByChild("participants/aniruddh").equalTo(true)
But this won't scale very well, as you'll need to define an index for each user.
The proper solution is to add a second data structure, known as an inverted index, that allows the look up of conversations for a user. In your case that could look like this:
userConversations: {
"aniruddh": {
"-LxzV5LzP9TH7L6BvV7": true
},
"trubluvin": {
"-LxzV5LzP9TH7L6BvV7": true
}
}
Now you can look up the conversations that a user is part of with a simple read operation. You could expand this data structure to contain more information on each conversation, such as the information you want to display in your list view.
Also see my answer heres:
Firebase query if child of child contains a value (for more explanation on why the queries won't work in your current structure, and why they won't scale in the first structure in my answer).
Best way to manage Chat channels in Firebase (for an alternative way of naming the chat rooms).
I'm trying to make an Activity log system or history for my docs, so every time a field is modified in a document i want to record or save that so i can see after changes history made on each document.
how i can achieve that ? i don't want to save the full doc on each change and then have tons of duplicated docs, if possible i just want to get the changed field (ex. name: 'john' -> name: 'jack').
i don't want to save the full doc on each change and then have tons of duplicated docs
Once a document has changed it becomes a new document. So you won't have duplicate documents unless you make changes that were previously made. Please also note that in Cloud Firestore there are no field-level permissions or access to a document. It's the entire document, or nothing. So if you want to change a field within a document for example from:
userName = "John"
into
userName = "Jack"
You'll will get the entire document and not only the userName property that has been changed.
Cloud Firestore listeners fire on the document level. There is no way to get triggered with just particular fields in a document.
If you want to get notified only of specific fields, consider adding an extra collection with documents that only contain those fields. This sort of data duplication is quite common in NoSQL solutions such as Firestore and for that, I recommend you see this video, Denormalization is normal with the Firebase Database for a better understanding. It is for Firebase real-time database but same principles apply to Cloud Firestore.
For a database schema you can also take a look at my answer from this post.
The best way to achieve something like this is to store the before and after changes happening to the doc, in a new document, which you can add in a subcollection. The changes are available with cloud functions onUpdate trigger. I have written in depth about this topic on my blog, have a look.
https://blog.emad.in/audit-logs-for-firestore-documents/
You can obtain this by creating a cloud function that triggers on all document updates in all collections:
--trigger-resource=projects/$PROJECT_ID/databases/(default)/documents/{collection_id}/{document_id}
In the cloud function you can obtain all the updated fields and their values through the data object.
Python example:
def main(data, context):
# Extract resource
resource = context.resource
resource_split = resource.split('/')
collection_name = resource_split[-2]
document_id = resource_split[-1]
# Get old fields
data_old_values = data['oldValue']
data_old_values_fields = data_old_values['fields']
# Get updated fields
data_updated_mask = data['updateMask']
data_updated_fields = data_updated_mask['fieldPaths']
# Get new field values
data_new_values = data['value']
data_new_values_fields = data_new_values['fields']
# `data_updated_fields` is a list of the fields that has been changed
# `data_old_values_fields` is a dictionary with the old values of the document
# `data_new_values_fields` is a dictionary with the new values of the document
I have a question regarding authentication using Google Firebase.
For an app, I want to build an authentication similar to the one Slack uses: first, the user provides the input as to which group they want to log in to. If there exists a group with the same name as provided in the input, the user is then taken to a login/signup screen.
I've thought about storing users in the realtime database as follows, but I think there must be a better way to do this (since I don't think I can use the firebase authentication in this case):
groups: {
"some_group_name": {
"users": [
"user1": {
.. user 1 information
},
"user2": {
.. user 2 information
}
],
"group_details": {
"name": ..,
"someGroupDetail": ..
}
},
"some_other_group_name": {
...
}
}
I haven't realized if there is an obvious answer yet, so I'm open to suggestions. How would you suggest I tackle this?
Thanks
PS: I'm building the application using Nativescript and Angular, and (so far) there is no server or database involved other than Firebase.
Another suggestion that might work, is by using Firebase Auth Custom Claims. That way, you only need to store the group ID and group name in your realtime database, without worrying to keep changing the database each time user is added or removed.
This is one way you can do it:
Store database exactly like you have it, with it's group ID and name.
In your backend script (I recommend Cloud Function), each time a User is registering themselves, add custom claims in your user: Specifying what group is the User belong to.
Every time user authenticate, retrieve the group ID from custom claims. And there you get it!
Note: be careful not to put too much information in your custom claims as it cannot exceed 1000 bytes.
Read more about it here: https://firebase.google.com/docs/auth/admin/custom-claims
I would suggest you to implement Root-level collections.
Which is to create collections at the root level of your database to organize disparate data sets(as shown in the image below).
Advantages: As your lists grow, the size of the parent document doesn't change. You also get full query capabilities on
subcollections.
Possible use case: In the same chat app, for example, you
might create collections of users or messages within chat room
documents
Based on the reference from the firebase cloud firestore
Choose a data structure tutorial (I know you are using Realtime database but structuring the database is the same since both are using the NoSQL Schema)
For your case:
Make 2 Collections: Users, Groups
Users: User info is stored in the form of document
Groups: In the Groups Collection, here comes the tricky part, you can either store all groups subcollection under 1 document or split into multiple documents (based on your preference)
In the group-subcollection, you can now store your group info as well as the user assigned where you can store user assigned in the form of array, therefore whenever a user access the group, query the user assigned first, if yes, then allow (assuming users can view all group)
You do the thinking now
I am building an iOS app that is using Cloud Firestore (not Firebase realtime database) as a backend/database.
Google is trying to push new projects towards Cloud Firestore, and to be honest, developers with new projects should opt-in for Firestore (better querying, easier to scale, etc..).
My issue is the same that any relational database developer has when switching to a no-SQL database: data modeling
I have a very simple scenario, that I will first explain how I would configure it using MySQL:
I want to show a list of posts in a table view, and when the user clicks on one post to expand and show more details for that post (let say the user who wrote it). Sounds easy.
In a relational database world, I would create 2 tables: one named "posts" and one named "users". Inside the "posts" table I would have a foreign key indicating the user. Problem solved.
Poor Barry, never had the time to write a post :(
Using this approach, I can easily achieve what I described, and also, if a user updates his/her details, you will only have to change it in one place and you are done.
Lets now switch to Firestore. I like to think of RDBMS's table names as Firestore's collections and the content/structure of the table as the documents.
In my mind i have 2 possible solutions:
Solution 1:
Follow the same logic as the RDBMS: inside the posts collection, each document should have a key named "userId" and the value should be the documentId of that user. Then by fetching the posts you will know the user. Querying the database a second time will fetch all user related details.
Solution 2:
Data duplication: Each post should have a map (nested object) with a key named "user" and containing any user values you want. By doing this the user data will be attached to every post it writes.
Coming from the normalization realm of RDBMS this sounds scary, but a lot of no-SQL documents encourage duplication(?).
Is this a valid approach?
What happens when a user needs to update his/her email address? How easily you make sure that the email is updated in all places?
The only benefit I see in the second solution is that you can fetch both post and user data in one call.
Is there any other solution for this simple yet very common scenario?
ps: go easy on me, first time no-sql dev.
Thanks in advance.
Use solution 1. Guidance on nesting vs not nesting will depend on the N-to-M relationship of those entities (for example, is it 1 to many, many to many?).
If you believe you will never access an entity without accessing its 'parent', nesting may be appropriate. In firestore (or document-based noSQL databases), you should make the decision whether to nest that entity directly in the document vs in a subcollection based on the expect size of that nested entity. For example, messages in a chat should be a subcollection, as they may in total exceed the maximum document size.
Mongo, a leading noSQL db, provides some guides here
Firestore also provided docs
Hope this helps
#christostsang I would suggest a combination of option 1 and option 2. I like to duplicate data for the view layer and reference the user_id as you suggested.
For example, you will usually show a post and the created_by or author_name with the post. Rather than having to pay additional money and cycles for the user query, you could store both the user_id and the user_name in the document.
A model you could use would be an object/map in firestore here is an example model for you to consider
posts = {
id: xxx,
title: xxx,
body: xxx,
likes: 4,
user: {refId: xxx123, name: "John Doe"}
}
users = {
id: xxx,
name: xxx,
email: xxx,
}
Now when you retrieve the posts document(s) you also have the user/author name included. This would make it easy on a postList page where you might show posts from many different users/authors without needed to query each user to retrieve their name. Now when a user clicks on a post, and you want to show additional user/author information like their email you can perform the query for that one user on the postView page. FYI - you will need to consider changes that user(s) make to their name and if you will update all posts to reflect the name change.