I'm following the docs for Firestore here on Aggregation Queries.
I couldn't help but notice that the cloud function solution wouldn't exactly work since it's not idempotent: numRatings is incremented and avgRating recomputed each time.
Though this example could be made idempotent if there was also a separate document being stored for each new rating: you'd add a check if the user has already submitted a rating for the restaurant.
Is there something I'm missing that makes this example idempotent? Or is the point of the example just to show that this could be done in a cloud function?
Making a function idempotent requires a lot of extra lines of code, which would make the example much harder to understand. You should expect that sample code not to be idempotent, unless it's trying to demonstrate idempotence.
If you have feedback for the authors of the documentation, you are free to give that with the "SEND FEEDBACK" button at the top of each page.
Related
Firebase documentation recommends including code snippet given at (https://firebase.google.com/docs/functions/networking#https_requests) to optimize the networking, but few details are missing. Like
How exactly does this help?
Are we supposed to call the function defined as per of recommendation
or include this snippet deploy?
Any documentation around this would be of great help.
this is an example showing you how you would make this request, the key part in this example is the agent field which by nature isn't normally managed within your app. By injecting a reference to it manually, you are able to micro-manage it and it's events directly.
As for the second question, it really depends on your cloud function needs - some users set it in a global object that they manage with all cloud functions but it's on a by-use case basis. but ultimately isn't required.
You can read more about HTTP.Agent's and their usage below:
https://nodejs.org/api/http.html
https://www.tabnine.com/code/javascript/functions/http/Agent
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/User-Agent
I'm using Google Firestore for a project and the "Cloud Firestore" interface for dealing with the database expands all document fields by default. This makes it tough to alter the data as I have a few large arrays in my sample data that cause me to have to collapse many fields before reaching the desired field.
Is there a way to set the data/fields to be collapsed by default? This is mainly a quality of life thing while I'm in MVP mode. For reference I've checked the documentation, reddit and stack overflow for an answer but haven't found a solution. I've also submitted this as a feature request just in case.
Edit for comment:
To clarify, I am referring to the console.firebase.google UI for Firestore. See the attached image (random image from google) for reference.
It's not possible to change the behavior of the console in the way you're suggesting. The way in which you add the data makes no difference.
I'm writing an app with a database of users. I want to show these to people on the app, and as such, in order to limit the download of data, I'm using the standard Firebase pagination concept:
.startAtDocument(lastDocumentSeen)
The problem is, I have no idea what actually happens when the 'read head' gets to the end of the database? Does Firebase/Flutter loop back and start to look at the top of the database again? If not, how does it signal to me that I've reached the end?
I've done quite extensive googling about this, and searched StackOverflow too, but can't seem to find any clear answers - does anyone know?
Assuming you have a query like this:
collectionRef.orderBy("something").startAfter(cursor).limit(10)
If there are not enough documents to return 10 results, Firestore will simply return however many documents are left. It does not perform any tricks beyond that.
You can use fetch_more package for pagination, it’s easy to use. You can see an example in the Example tab.
https://pub.dev/packages/fetch_more
I'm using tdlib and currently trying to create another user's profile screen like this one:
There is usually a field on this screen called "Notifications" containing information on whether or not notifications for given user are muted and if so then for how long. All other fields seem easy to retrieve, but this one is a head-scratcher for me.
All other field are stored in User entity, but what am I supposed to do with this one? Call createPrivateChat only to get one field (namely notificationSettings)? This seems like overkill to me. Isn't there easiest ways to get this? In this issue sapelkinAV states that "chatID is equals UserId". Is it correct? Even if so it might just be an internal thing that we shouldn't rely on, and I can't find neither proofs nor restrictions on abusing this "feature".
If it is fine, than I could use getNotificationSettings and pass notificationSettingsScopeChat as scope parameter. Would it be the right solution? Any thoughts and advices are appreciated!
Official answer (obtained from TDLib bot):
Your usage of createPrivateChat is absolutely correct. To get correct NotificationSettings you need to get information about the corresponding chat.
So I ended up doing exactly that.
Call createPrivateChat only to get one field (namely notificationSettings)?
I'm considering to use Firebase for a project but can't seem to find any informations on server-side data validation.
Lets say i'm making a game and a player deals damage to another player i would like to validate the following:
That the players are actually close to eachother
That the damage points corresponds to the attack given
That the data has not been
tampered from the client to the server
ETC.
Is it possible to validate this kind of stuff /Adding serverside logic directly with Firebase or do i have to make an intermediate-server, basically smashing the whole point in using Firebase in the first place?
Thanks in advance
Jonas
Validating data is definitely possible with Firebase. It is part of its "security" rules, for which the documentation can be found here and here.
A simple example from that last documentation link:
a sample .validate rule definition which only allows dates in the format YYYY-MM-DD between the years 1900-2099, which is checked using a regular expression.
".validate": "newData.isString() &&
newData.val().matches(/^(19|20)[0-9][0-9][-\\/. ](0[1-9]|1[012])[-\\/. ](0[1-9]|[12][0-9]|3[01])$/)"
You can build pretty complicated validation rules. In case you need those, you might want to have a look at Firebase's blaze compiler. It translates a higher-level language into Firebase's relatively low-level rules. The author of the blaze compiler originally wrote it for your second and third use-case and wrote an article about it here.
I hope these are enough to get you started. If you get stuck, just post a question with the rules you tried.