When using push() Firebase creates a unique ID or key such as -KKm9iRSax-scGn7m3Lb.
According to the docs:
The push() method generates a unique ID every time a new child is
added to the specified Firebase reference.
And:
The unique ID generated by push() is based on a timestamp, so list
items are automatically ordered chronologically.
Is this ID or key unique to the whole database or only to the reference (like /users)?
Firebase keys are part timestamp and part random characters. So while they should be unique across the whole database there is a small chance that two keys could end up being the same.
Firebase blog: The 2^120 Ways to Ensure Unique Identifiers
Related
I'm creating an application for generating documents with unique id, my issue is that the id needs to be in a specific format ( 00000/A/B) so I can't use firestore document's id's.
The problem is also that I have that id's in different places,
#1 case
users/{userID}/id = //UNIQUE ID HERE
#2 case
users/{userID}/members <= members is an array of objects where every member need a unique id
I was thinking about the separate collection of id's where I can check which one is taken but maybe is there a better way to ensure id is unique across the whole app?
What you're considering is pretty much the only way to guarantee uniqueness of a value across the database.
In a few more structured steps, it'd be:
Use that value as the document ID in an secondary collection. This collection purely exists to ensure uniqueness of the IDs.
Let the user claim it, typically by writing their UID into the document.
Use security rules to ensure a user can only write a document if it doesn't exist yet, and (if needed) only deleted when they own it.
The topic of unique values has been covered quite a few times before, although usually in the form of unique user names, so I recommend checking out:
Cloud Firestore: Enforcing Unique User Names
How to generate and guarantee unique values in firestore collection?
How to enforce Uniqueness in a Property of a document field in Google Cloud Firestore
Firestore unique index or unique constraint?
I want to make unique usernames in firebase/firestore
I'm using APP inventor 2 and firebase to store same multiple "like" values for different KEYs. I'm using a like and nolike counters set initially to 0. Firebase stores the values for the different Keys but when I increase the value for the first KEY and call the other KEY, the second KEY takes over this value instead starting from null or the value saved in firebase. I guess I have to zero the like and nolike counters every time after I store a value for a Key so the next KEY doesn't start with the value from the first KEY and I tried but is not working ... I'm trying to avoid setting counters for every like and notlike button for every mainKEYS as there are a lot of mainKEYS. I'm not sure if this is understandable... all examples I found are for names and text strings, but no for (multiple) counters
I am confused about the functionality of push() in Firebase, even after reading the docs. They present the following code:
// Generate a reference to a new location and add some data using push()
var newPostRef = postsRef.push();
// Get the unique ID generated by push()
var postID = newPostRef.key();
Does push() conduct a server query to get a unique ID (thus lagging the main thread--which seems not smart), or does it simply create a "dirty" unique ID that is later checked for uniqueness against the master ledger in the server? The docs seem kind of unclear about the robustness of the ID so I want to make sure.
Firebase's push() method is a pure client-side method. It generates a key based on the current time (corrected for the last known offset of the local clock from the server) and a lot of random information. The key it generates is statistically guaranteed to be unique.
To learn more about these keys, see this blog post: The 2^120 Ways to Ensure Unique Identifiers.
In Firebase if I'd like to create a child node with a unique ID it appears I have two options:
Push() :
Use the push() method to append data to a list in multiuser
applications. The push() method generates a unique ID every time a new
child is added to the specified Firebase reference. By using these
auto-generated keys for each new element in the list, several clients
can add children to the same location at the same time without write
conflicts. The unique ID generated by push() is based on a timestamp,
so list items are automatically ordered chronologically.
childByAutoId:
childByAutoId generates a new child location using a unique key and
returns a FIRDatabaseReference to it. This is useful when the children
of a Firebase Database location represent a list of items. The unique
key generated by childByAutoId: is prefixed with a client-generated
timestamp so that the resulting list will be chronologically-sorted.
Whats the difference?
Nevermind, it appears they are the same except they cater to different platforms:
Save Data on IOS
childByAutoId : Add to a list of data. Every time you call childByAutoId, Firebase generates a unique ID, such as user-posts/<user-id>/<unique-post-id>.
Save Data on Web
push() : Add to a list of data. Every time you call push(), Firebase generates a unique ID, such as user-posts/<user-id>/<unique-post-id>.
I've been creating a consumer who "grants" ids to clients when they perform certain tasks. It occurred to me at some point that it might be entirely superfluous to worry about the path before I do a .push().name() to create new ids.
Does it matter what path I run the .push().name() on to create a unique ID? Does Firebase generate the IDs entirely based on timestamp, without regard to the path the ID will be assigned to?
Currently, push() ids are generated based on timestamps (along with some randomness). The path on which the id is being pushed is not used as part of the id.