I am working with firebase real time database. Every time I push the data into the firebase using push method it auto generates a key like this
"-L1GgaMStpwEV4N3sQad" to my best knowledge it's generated based on time also.
So my question is there any way to sort the key asce or in desc?.
I have attached image of firebase auto generated.
Thanks in advance.
I new to firebase but here's my observation :
The unique keys that are generated are already sorted in Lexicographical order.
Have a closer look at your objects:
-L1GgaM is common for all keys (except last which ends with 'N')
Also, remember that capital letters have lower ASCII value than their counterpart.
Related
Whenever I set a large value eg: 293844625770502555 to firebase realtime db via firebase console/SDK, it is auto round off to another value eg: 293844625770502500.
Anyone has any idea what could be wrong here?
You've exceeded the limits of JavaScript numbers (2^53).
You need to use either to make use of classes like BigInt and/or force Firebase to store the value as a string by adding a letter to the front like "n293844625770502555" and then manually convert the number back.
In my app I use Firebase's childByAutoId() (swift) or .push() (web) to insert some data in the following format:
- events
- $autoId
- time:
- name:
- $autoId
- time:
- name:
Where $autoId are the randomly generated keys Firebase makes. time is the epoch time of when the data was pushed.
I want to allow users to modify each inserted entry's time. However, I want to keep the nodes under events sorted by their key and by time which Firebase naturally does when you use .push(). But if they modify the time so that it should actually be in a different order, the entries won't be sorted correctly.
Is there a way to generate an id by the modified time so that if it were inserted into events it would be in the right order? That way I could just delete the old entry and insert the new one while just duplicating the data.
Since the algorithm for Firebase's push IDs is well documented, you could easily modify the function to generate them based on a specific timestamp.
But I'd recommend instead keeping the necessary values as named properties for each child node. If you need to be able to sort by both creation and modification time, keep two separate properties. That way you won't have to depend on the behavior of the push IDs, but instead use more explicitly named properties to accomplish what you need.
I have a root in firebase like in the I am trying to enable user to delete an item on list. But user can give up his decision. When user give up this decision, I want to insert the deleted item again in the database. But, I want to insert with old firebase generated key, because I am using firebase push keys. Is that a bad practice. How firebase generate these keys? Does it checks every key on db and generate a new one? Is that any possibility, that key marked as removed and generated later for another item? Sorry for the language. It has been hard to express.
EDITED: I want to use the old key because, I am getting the data with orderByKey. I dont want to lose order.
How firebase generate these keys? Does it checks every key on db and generate a new one?
Whenever you use push on a Database Reference, a new data node is generated with a unique key that includes the server timestamp. These keys look like -KiGh_31GA20KabpZBfa.
Because of the timestamp, you can be sure that the given key will be unique, without having to check the other keys inside your database.
Is that any possibility, that key marked as removed and generated later for another item?
No, it is not possible that two keys will collide, regardless of wether one has been removed or not.
But, I want to insert with old firebase generated key, because I am using firebase push keys. Is that a bad practice
Unfortunately, you can't generate the same key twice by just using push. So, it is not possible to delete a node with a given key and then use push to insert it again at the same path with the same key, because push would generate a different and unique key.
Instead of this, if ordering by key is that important to you, and there's a possibility that a deleted node can be reinserted then I would recommend you to do one of the following :-
Either save the key on the client side when it's deleted from the database, and use it when you need to reinsert.
Or , maybe, have a "deleted-keys" path in your database and save the deleted keys there. Of course, with this approach, you'd need to store additional information to identify the data that the key corresponds to.
It all really depends on your use case.
Calling push() will generate a key for you.
If instead you use child(), you can determine they key/path yourself.
ref.child("yourvalue").setValue("setting custom key when pushing new data to firebase database");
https://firebase.googleblog.com/2015/02/the-2120-ways-to-ensure-unique_68.html
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've read almost everywhere about structuring one's Firebase Database for efficient querying, but I am still a little confused between two alternatives that I have.
For example, let's say I want to get all of a user's "maxBenchPressSessions" from the past 7 days or so.
I'm stuck between picking between these two structures:
In the first array, I use the user's id as an attribute to index on whether true or false. In the second, I use userId as the attribute NAME whose value would be the user's id.
Is one faster than the other, or would they be indexed a relatively same manner? I kind of new to database design, so I want to make sure that I'm following correct practices.
PROGRESS
I have come up with a solution that will both flatten my database AND allow me to add a ListenerForSingleValueEvent using orderBy ONLY once, but only when I want to check if a user has a session saved for a specific day.
I can have each maxBenchPressSession object have a key in the format of userId_dateString. However, if I want to get all the user's sessions from the last 7 days, I don't know how to do it in one query.
Any ideas?
I recommend to watch the video. It is told about the structuring of the data very well.
References to the playlist on the firebase 3
Firebase 3.0: Data Modelling
Firebase 3.0: Node Client
As I understand the principle firebase to use it effectively. Should be as small as possible to query the data and it does not matter how many requests.
But you will approach such a request. We'll have to add another field to the database "negativeDate".
This field allows you to get the last seven entries. Here's a video -
https://www.youtube.com/watch?v=nMR_JPfL4qg&feature=youtu.be&t=4m36s
.limitToLast(7) - 7 entries
.orderByChild('negativeDate') - sort by date
Example of a request:
const ref = firebase.database().ref('maxBenchPressSession');
ref.orderByChild('negativeDate').limitToLast(7).on('value', function(snap){ })
Then add the user, and it puts all of its sessions.
const ref = firebase.database().ref('maxBenchPressSession/' + userId);
ref.orderByChild('negativeDate').limitToLast(7).on('value', function(snap){ })