Im very new to Android development. At the moment I am trying to develop my first app. My app is going to have a friend-system. Im trying to setup the Firestore-database to match my conditions.
I want to use the UserID provided by the google authentication to control the access of the database.
Every user has a friendlist of usernames,since I think, its not safe to let any client know the UserID of another client.
My Firestore database looks like this:
"users" (collection)
UserID (document)
DisplayName, Username (fields)
"friendlist"
UserID
Username1,Username2,Username3...
Everytime I want to access data of a user inside my friendlist a have to retrieve data from the users-collection using the UserID-document. Since the client isnt allowed to know the UserID of the friend, I need another collection which I am planing to access through cloud functions to know which userID belongs to the username.
"usernames" (collection)
Username (document)
UserID (fields)
Is there a better way to minimize database-reads while protecting database accesses?
You could try looking for the UserID(document) based on the Username filed taking the answer from this other thread as a starting point.
Nevertheless, you would need to make sure that the Usernames do not repeat as this may cause issues later on by programming a check in the insertion of updates of usernames.
Otherwise, the solution you are planning would work although with the caveat that you may get a higher billing in the future as you are billed for every read as mentioned here.
Hope you find this useful!
Related
I have a use case where I want to connect two different user roles, and if they accept and want to connect, new features will open up. It is very similar to how friend requests work at Facebook or LinkedIn, opening up and showing more content. Let's call them role1 and role2.
All users are stored within a "users" collection with an id. Depending on their provided role within the document attached to the "users" collection, they can store additional data in their respective role-collection, i.e., role1 collection or role2 collection.
What is the best approach and structure to connect the two users, i.e., become "friends"? Should I have the connection stored in a new collection, named perhaps connections-collection, or multiple collections?
I'm using Next.js, NextAuth for user authentication, and FaunaDB as a database. I'm using Fauna's query language, FQL.
Have you perhaps seen fireship's video RE: fauna db? I think it covers what you want to do and how you can proceed.
Edit: There are many ways to implement this. Based on my understanding, perhaps you can have "Friends" and "Requests" arrays stored under a user document. That way you can differentiate between confirmed friends or a just request.
Example: When user1 initiates a friend request with user2, you store user1's ref under "Requests" of user2's document. When user2 confirms, you move user1's ref to the "Friends" array.
This is just a overly simplified idea and you may need to consider your options and the implications. You would need to plan and define the predicate in both roles so you would only see what is necessary.
been working on this app with react native and have been implementing persistence for some functionality with Async Storage.... but a big detail kinda flew over my head.
For the user to use the app they have to log in, and it works perfectly for one user, all data is kept and all..... but if on the same device, a different user logs in then I get the data stored in the async storage from the previews user... which is kinda of obvious, but didn't even think of that.
I can't seem to think of a way I could differ that info for different users? the only data I could use to differ each user would be the email they use to log in... would I have to create a different entry on the storage with the email as a key and then do a logic to check if it is theirs or some other users info?
any ideas on the best practice for this situation?
Thank you in advance
You could make your keys for different users distinct by starting each key with a user's email. Example:
Joe:
AsyncStorage.setItem('joe#website.com/userId', jsonValue)
James:
AsyncStorage.setItem('james#website.com/userId', jsonValue)
Another option is that every time a user logs out of your app you could clear the AsyncStorage using await AsyncStorage.clear().
We are trying to develop a SCIM enabled Provisioning system for provisioning data from an Enterprise Cloud Subscriber(ECS) to Salesforce(Cloud Service Provider-CSP). We are following SCIM 1.1 standard.
What are we able to do:
We are able to perform CRUD operations on User object using Salesforce auto-generated userId field
Exact Problem:
We are not able to update/delete User object using externalId provided by ECS.
Tried something as below... But it is not working, Unknown_Exception is thrown...
XXX/my.salesforce.com/services/scim/v1/Users/701984?fields=externalId
Please note that it is not possible to store Salesforce userId in ECS's database due to some compliance reasons. So we have to completely depend upon externalId only.
Possible Workaround:
Step1: Read the userId based on externalId from Salesforce
Step2: Update the User object using the salesforce UserId obtained in Step1.
But this two step process would definitely degrade the performance.
Is there any way to update/delete the User by externalId
Could you please guide us on this..
Thanks so much....
I realize this is old thread but wanted to note that you CAN update Users from REST using an external ID. The endpoint in above question is incorrect. Following is how it should be set, send as a PATCH request:
[instance]/services/data/v37.0/sobjects/user/[external_id__c]/[external id value]
Instance = your instance i.e. https://test.salesforce.com/
external_id__c = API name of your custom external Id field on User
external id value = whatever the value of the user's external Id
NOTES:
Salesforce responds with an HTTP 204 status code with No Content in the body, this isn't usual for patch requests, but it is 'success' response
The external id on user has to be a custom field, make sure it is set
as UNIQUE
Ensure the profile/permission set of the user that is making the call
has the Manage Users permission & has access to the external id field
It is pretty common pattern for other applications, too, to search first and then perform on update on the returned object. Your workaround seems fine to me. What performance problem are you concerned about? Are you concerned about Salesforce not being able to process more requests or are you concerned about the higher response time in your application because you need to make multiple requests? Have you actually measured how much an extra call costs?
Im using Parse to save data from my social network. So far I have three class: Users, Posts, and Relationships. I want the user to be able to like a post.
Should I create a new table for Likes. If so, then on my storyboard page I would have to query through Relationships to get the user followers, then Posts to get the posts from the followers, and then Likes to get the likes from those posts?
Is it efficient to have three API requests to parse on one page. I feel like this will slow down performance but I'm not sure how else to save likes.
Another thing is, I would like to display a notifications tableView. So all likes and requested follows. So Im guessing I would save likes in Relationships and just query through it twice on the storyboard to first get followers, then likes. And on the notification page, have one class to query though once to get all recent notifications.
What are your suggestions?
Thanks.
This is sort of a broad question so there is no way that I could say for sure, but I do have a couple suggestion that you can do with parse.com.
Use the local datastore: You can save all of the likes that the user has in the local datastore as well as in the cloud of your application. So, for instance, you create the like when the user likes something, save it to the cloud, and then pin it to the local datastore. That way, you can efficiently query all of the likes that your user has created without using an API request. But in the event the user logs into the app somewhere else, you also have the likes in the cloud to retrieve. So, I would create a new table for likes.
You could use a join table to implement the followers, so, you could also pin the followers of the user to the local datastore like you would for a like. This is like is done in the Parse.com anypic tutorial.
I would also have another table for notifications. In cloud code, you could even update how many notifications the user has with an afterSave method, and then get all the notifications through a query when requested by the user.
I would like to create an email workflow using an Access Web DB form to manage holiday requests. The user will create a request from the form, save it - which triggers the SendMail data macro, ideally with a link in it for the approver to click and go to the approval form filtered to the correct request ID.
Does anybody know:
a) If it is possible to load the form in the browser filtered at the specific record ID. I have tried appending ?ID=1 to the form URL and so on, without any joy so far.
https://mysharepointserver.com/sites/mywebapp/default.aspx?ID=1
b) If possible, what steps do I need to go through to get it working?
This is an Access 2010 web database hosted on a heavily bespoke Sharepoint platform. Any help appreciated.
I have worked it out, using:
?Page={ID}
However, the one caveat with this is that if you delete a record then the page number refers to the records position in the table, not specifically the ID. If you can ensure that records are never deleted from the table it will remain aligned with Page number and ID number.
Its a bit of a pain, but if anyone finds a way of referencing ID directly that would be the ideal solution.
You can also use something along the lines of:
http://...sp_site_path.../default.aspx#Type=Form&Path=NavForm.Subform&Name=ActualForm&DataMode=Edit&Where=%3DID%3D1000
I believe the key part here is...
&Where=%3DID%3D1000
...which in this case refers to the database field [ID] and record 1000, ie:
[ID]=1000
The rest of the URL is refers to a specfic form within your site, however is you only have one, it is potentially not important for your purpose, and you would be able to get by with something like:
http://...sp_site_path.../default.aspx#Where=%3DID%3D1000
Since all my sites use navigation pages, I haven't tested this out