Overcoming firestore update slight delay2019 Community Moderator ElectionInternal error in Firestore (0.6.6-dev) when trying to update documentListeners not being updated in FirestoreFireStore Update Document doesn´t workminimize time operation in firebase/firestoreIs Firestore onSnapshot update event due to local client Set?Django Authentication with Firebase/FirestoreFirestore: how can I get stream of updates from a server side?Firebase Cloud Firestore Snapshot listen too fastAtomic way to create firebase auth account and firestore entryFirestore Real Time updates connection in NodeJS
Instead of Universal Basic Income, why not Universal Basic NEEDS?
Why did it take so long to abandon sail after steamships were demonstrated?
SQL Server Primary Login Restrictions
Make a transparent 448*448 image
Rules about breaking the rules. How do I do it well?
Can anyone tell me why this program fails?
Provisioning profile doesn't include the application-identifier and keychain-access-groups entitlements
Calculus II Professor will not accept my correct integral evaluation that uses a different method, should I bring this up further?
Replacing Windows 7 security updates with anti-virus?
Can hydraulic brake levers get hot when brakes overheat?
Life insurance that covers only simultaneous/dual deaths
What does it mean to make a bootable LiveUSB?
Does splitting a potentially monolithic application into several smaller ones help prevent bugs?
How to write cleanly even if my character uses expletive language?
Does the statement `int val = (++i > ++j) ? ++i : ++j;` invoke undefined behavior?
Should we release the security issues we found in our product as CVE or we can just update those on weekly release notes?
Is it possible that AIC = BIC?
How to simplify this time periods definition interface?
Why is "das Weib" grammatically neuter?
Why does Deadpool say "You're welcome, Canada," after shooting Ryan Reynolds in the end credits?
Professor being mistaken for a grad student
Co-worker team leader wants to inject his friend's awful software into our development. What should I say to our common boss?
Why must traveling waves have the same amplitude to form a standing wave?
How do I hide Chekhov's Gun?
Overcoming firestore update slight delay
2019 Community Moderator ElectionInternal error in Firestore (0.6.6-dev) when trying to update documentListeners not being updated in FirestoreFireStore Update Document doesn´t workminimize time operation in firebase/firestoreIs Firestore onSnapshot update event due to local client Set?Django Authentication with Firebase/FirestoreFirestore: how can I get stream of updates from a server side?Firebase Cloud Firestore Snapshot listen too fastAtomic way to create firebase auth account and firestore entryFirestore Real Time updates connection in NodeJS
What I'm trying to do is -
I'm getting a click from users on different clients,
and I need to know which one was the first to click.
I have a document that clients write to,
and my idea was to let clients change it, as long as it's an empty string.
Otherwise, if it's already filled (with a user id), you cannot apply a change.
This way, I'll be able to know which user has clicked first.
The problem with this solution, is that it's client sided,
and there's a slight delay, causing users that didn't click first,
to update their user id, because when they clicked, the real first user wasn't updated yet.
Now, I'm new to firestore & firebase, and my question is,
is there a way to overcome this problem?
I had another idea, to basically let all clients send current time to firestore,
and then check who is first, but I wonder if there's a way to go with my first idea, and make it work.
thx!
android firebase google-cloud-firestore
add a comment |
What I'm trying to do is -
I'm getting a click from users on different clients,
and I need to know which one was the first to click.
I have a document that clients write to,
and my idea was to let clients change it, as long as it's an empty string.
Otherwise, if it's already filled (with a user id), you cannot apply a change.
This way, I'll be able to know which user has clicked first.
The problem with this solution, is that it's client sided,
and there's a slight delay, causing users that didn't click first,
to update their user id, because when they clicked, the real first user wasn't updated yet.
Now, I'm new to firestore & firebase, and my question is,
is there a way to overcome this problem?
I had another idea, to basically let all clients send current time to firestore,
and then check who is first, but I wonder if there's a way to go with my first idea, and make it work.
thx!
android firebase google-cloud-firestore
add a comment |
What I'm trying to do is -
I'm getting a click from users on different clients,
and I need to know which one was the first to click.
I have a document that clients write to,
and my idea was to let clients change it, as long as it's an empty string.
Otherwise, if it's already filled (with a user id), you cannot apply a change.
This way, I'll be able to know which user has clicked first.
The problem with this solution, is that it's client sided,
and there's a slight delay, causing users that didn't click first,
to update their user id, because when they clicked, the real first user wasn't updated yet.
Now, I'm new to firestore & firebase, and my question is,
is there a way to overcome this problem?
I had another idea, to basically let all clients send current time to firestore,
and then check who is first, but I wonder if there's a way to go with my first idea, and make it work.
thx!
android firebase google-cloud-firestore
What I'm trying to do is -
I'm getting a click from users on different clients,
and I need to know which one was the first to click.
I have a document that clients write to,
and my idea was to let clients change it, as long as it's an empty string.
Otherwise, if it's already filled (with a user id), you cannot apply a change.
This way, I'll be able to know which user has clicked first.
The problem with this solution, is that it's client sided,
and there's a slight delay, causing users that didn't click first,
to update their user id, because when they clicked, the real first user wasn't updated yet.
Now, I'm new to firestore & firebase, and my question is,
is there a way to overcome this problem?
I had another idea, to basically let all clients send current time to firestore,
and then check who is first, but I wonder if there's a way to go with my first idea, and make it work.
thx!
android firebase google-cloud-firestore
android firebase google-cloud-firestore
asked Mar 7 at 12:10
tApjatApja
66110
66110
add a comment |
add a comment |
2 Answers
2
active
oldest
votes
I think you could benefit from the atomicity of transactions (https://firebase.google.com/docs/firestore/manage-data/transactions)
The transaction would look like this:
- read the string field
- if it is empty, write and return a 'first in success', if it is not, return a 'someone already there'
- If someone is already doing a transaction on this field, retry the transaction until the other transaction is terminated (firestore will automatically do that for you)
1
If I understand well: a user could overwrite thefirstToClick
string if he clicks when another user has already clicked? And write his ID infirstToClick
field instead of the other user (that was actually first)? If so, transaction atomicity would not permit that because you would systematically read from the database before changing it, checking for an empty string. If you succeed to write on it, you can be sure to be the only user writing on it with the implementation above. If they are both entering the transaction before sending it, only one of the 2 users will complete it.
– Quentin C
Mar 7 at 23:49
1
Yeah, exactly. So basically; user1 clicks, checks that the string is empty (it is), his id is being updated in the field; Meanwhile, user2 clicks just after user1 did, checks that the string is empty (it is, since user1 id wasn't updated just yet), his id is being updated in the field.
– tApja
Mar 7 at 23:54
1
From the doc: "For example, if a transaction reads documents and another client modifies any of those documents, Cloud Firestore retries the transaction." So yes, it would not happen. Latest user will get its transaction retried and finally return 'there is something in the string, I can't write to it'
– Quentin C
Mar 7 at 23:56
1
Okay now this is interesting, I'm going to try it out and let you know how it worked, thx!
– tApja
Mar 7 at 23:58
1
I gave your more details in my answer, thanks good luck!
– Quentin C
Mar 7 at 23:59
|
show 2 more comments
I would go with the date validation, but doing it on the client side wouldn't be very safe, because variations in local times could cause users to incorrectly be identified as early or late. To solve that I see two options:
The first one would be creating an HTTPS Cloud Function where you could get the server date and send it to the database. That way you are not influenced by the local date on your users' devices. You could also do the same by hosting this code anywhere you want and calling it with HTTP, the Cloud Function is just easier.
The other option would be first saving the date and the user to Realtime DB. It was created for realtime applications, so it will probably be faster than Firestore to write. You can then create a DB Cloud Function that would get the date and send it to Firestore, and there you can validate which user saved first.
add a comment |
Your Answer
StackExchange.ifUsing("editor", function ()
StackExchange.using("externalEditor", function ()
StackExchange.using("snippets", function ()
StackExchange.snippets.init();
);
);
, "code-snippets");
StackExchange.ready(function()
var channelOptions =
tags: "".split(" "),
id: "1"
;
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function()
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled)
StackExchange.using("snippets", function()
createEditor();
);
else
createEditor();
);
function createEditor()
StackExchange.prepareEditor(
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader:
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
,
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
);
);
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55043469%2fovercoming-firestore-update-slight-delay%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
I think you could benefit from the atomicity of transactions (https://firebase.google.com/docs/firestore/manage-data/transactions)
The transaction would look like this:
- read the string field
- if it is empty, write and return a 'first in success', if it is not, return a 'someone already there'
- If someone is already doing a transaction on this field, retry the transaction until the other transaction is terminated (firestore will automatically do that for you)
1
If I understand well: a user could overwrite thefirstToClick
string if he clicks when another user has already clicked? And write his ID infirstToClick
field instead of the other user (that was actually first)? If so, transaction atomicity would not permit that because you would systematically read from the database before changing it, checking for an empty string. If you succeed to write on it, you can be sure to be the only user writing on it with the implementation above. If they are both entering the transaction before sending it, only one of the 2 users will complete it.
– Quentin C
Mar 7 at 23:49
1
Yeah, exactly. So basically; user1 clicks, checks that the string is empty (it is), his id is being updated in the field; Meanwhile, user2 clicks just after user1 did, checks that the string is empty (it is, since user1 id wasn't updated just yet), his id is being updated in the field.
– tApja
Mar 7 at 23:54
1
From the doc: "For example, if a transaction reads documents and another client modifies any of those documents, Cloud Firestore retries the transaction." So yes, it would not happen. Latest user will get its transaction retried and finally return 'there is something in the string, I can't write to it'
– Quentin C
Mar 7 at 23:56
1
Okay now this is interesting, I'm going to try it out and let you know how it worked, thx!
– tApja
Mar 7 at 23:58
1
I gave your more details in my answer, thanks good luck!
– Quentin C
Mar 7 at 23:59
|
show 2 more comments
I think you could benefit from the atomicity of transactions (https://firebase.google.com/docs/firestore/manage-data/transactions)
The transaction would look like this:
- read the string field
- if it is empty, write and return a 'first in success', if it is not, return a 'someone already there'
- If someone is already doing a transaction on this field, retry the transaction until the other transaction is terminated (firestore will automatically do that for you)
1
If I understand well: a user could overwrite thefirstToClick
string if he clicks when another user has already clicked? And write his ID infirstToClick
field instead of the other user (that was actually first)? If so, transaction atomicity would not permit that because you would systematically read from the database before changing it, checking for an empty string. If you succeed to write on it, you can be sure to be the only user writing on it with the implementation above. If they are both entering the transaction before sending it, only one of the 2 users will complete it.
– Quentin C
Mar 7 at 23:49
1
Yeah, exactly. So basically; user1 clicks, checks that the string is empty (it is), his id is being updated in the field; Meanwhile, user2 clicks just after user1 did, checks that the string is empty (it is, since user1 id wasn't updated just yet), his id is being updated in the field.
– tApja
Mar 7 at 23:54
1
From the doc: "For example, if a transaction reads documents and another client modifies any of those documents, Cloud Firestore retries the transaction." So yes, it would not happen. Latest user will get its transaction retried and finally return 'there is something in the string, I can't write to it'
– Quentin C
Mar 7 at 23:56
1
Okay now this is interesting, I'm going to try it out and let you know how it worked, thx!
– tApja
Mar 7 at 23:58
1
I gave your more details in my answer, thanks good luck!
– Quentin C
Mar 7 at 23:59
|
show 2 more comments
I think you could benefit from the atomicity of transactions (https://firebase.google.com/docs/firestore/manage-data/transactions)
The transaction would look like this:
- read the string field
- if it is empty, write and return a 'first in success', if it is not, return a 'someone already there'
- If someone is already doing a transaction on this field, retry the transaction until the other transaction is terminated (firestore will automatically do that for you)
I think you could benefit from the atomicity of transactions (https://firebase.google.com/docs/firestore/manage-data/transactions)
The transaction would look like this:
- read the string field
- if it is empty, write and return a 'first in success', if it is not, return a 'someone already there'
- If someone is already doing a transaction on this field, retry the transaction until the other transaction is terminated (firestore will automatically do that for you)
edited Mar 8 at 0:11
answered Mar 7 at 21:37
Quentin CQuentin C
1728
1728
1
If I understand well: a user could overwrite thefirstToClick
string if he clicks when another user has already clicked? And write his ID infirstToClick
field instead of the other user (that was actually first)? If so, transaction atomicity would not permit that because you would systematically read from the database before changing it, checking for an empty string. If you succeed to write on it, you can be sure to be the only user writing on it with the implementation above. If they are both entering the transaction before sending it, only one of the 2 users will complete it.
– Quentin C
Mar 7 at 23:49
1
Yeah, exactly. So basically; user1 clicks, checks that the string is empty (it is), his id is being updated in the field; Meanwhile, user2 clicks just after user1 did, checks that the string is empty (it is, since user1 id wasn't updated just yet), his id is being updated in the field.
– tApja
Mar 7 at 23:54
1
From the doc: "For example, if a transaction reads documents and another client modifies any of those documents, Cloud Firestore retries the transaction." So yes, it would not happen. Latest user will get its transaction retried and finally return 'there is something in the string, I can't write to it'
– Quentin C
Mar 7 at 23:56
1
Okay now this is interesting, I'm going to try it out and let you know how it worked, thx!
– tApja
Mar 7 at 23:58
1
I gave your more details in my answer, thanks good luck!
– Quentin C
Mar 7 at 23:59
|
show 2 more comments
1
If I understand well: a user could overwrite thefirstToClick
string if he clicks when another user has already clicked? And write his ID infirstToClick
field instead of the other user (that was actually first)? If so, transaction atomicity would not permit that because you would systematically read from the database before changing it, checking for an empty string. If you succeed to write on it, you can be sure to be the only user writing on it with the implementation above. If they are both entering the transaction before sending it, only one of the 2 users will complete it.
– Quentin C
Mar 7 at 23:49
1
Yeah, exactly. So basically; user1 clicks, checks that the string is empty (it is), his id is being updated in the field; Meanwhile, user2 clicks just after user1 did, checks that the string is empty (it is, since user1 id wasn't updated just yet), his id is being updated in the field.
– tApja
Mar 7 at 23:54
1
From the doc: "For example, if a transaction reads documents and another client modifies any of those documents, Cloud Firestore retries the transaction." So yes, it would not happen. Latest user will get its transaction retried and finally return 'there is something in the string, I can't write to it'
– Quentin C
Mar 7 at 23:56
1
Okay now this is interesting, I'm going to try it out and let you know how it worked, thx!
– tApja
Mar 7 at 23:58
1
I gave your more details in my answer, thanks good luck!
– Quentin C
Mar 7 at 23:59
1
1
If I understand well: a user could overwrite the
firstToClick
string if he clicks when another user has already clicked? And write his ID in firstToClick
field instead of the other user (that was actually first)? If so, transaction atomicity would not permit that because you would systematically read from the database before changing it, checking for an empty string. If you succeed to write on it, you can be sure to be the only user writing on it with the implementation above. If they are both entering the transaction before sending it, only one of the 2 users will complete it.– Quentin C
Mar 7 at 23:49
If I understand well: a user could overwrite the
firstToClick
string if he clicks when another user has already clicked? And write his ID in firstToClick
field instead of the other user (that was actually first)? If so, transaction atomicity would not permit that because you would systematically read from the database before changing it, checking for an empty string. If you succeed to write on it, you can be sure to be the only user writing on it with the implementation above. If they are both entering the transaction before sending it, only one of the 2 users will complete it.– Quentin C
Mar 7 at 23:49
1
1
Yeah, exactly. So basically; user1 clicks, checks that the string is empty (it is), his id is being updated in the field; Meanwhile, user2 clicks just after user1 did, checks that the string is empty (it is, since user1 id wasn't updated just yet), his id is being updated in the field.
– tApja
Mar 7 at 23:54
Yeah, exactly. So basically; user1 clicks, checks that the string is empty (it is), his id is being updated in the field; Meanwhile, user2 clicks just after user1 did, checks that the string is empty (it is, since user1 id wasn't updated just yet), his id is being updated in the field.
– tApja
Mar 7 at 23:54
1
1
From the doc: "For example, if a transaction reads documents and another client modifies any of those documents, Cloud Firestore retries the transaction." So yes, it would not happen. Latest user will get its transaction retried and finally return 'there is something in the string, I can't write to it'
– Quentin C
Mar 7 at 23:56
From the doc: "For example, if a transaction reads documents and another client modifies any of those documents, Cloud Firestore retries the transaction." So yes, it would not happen. Latest user will get its transaction retried and finally return 'there is something in the string, I can't write to it'
– Quentin C
Mar 7 at 23:56
1
1
Okay now this is interesting, I'm going to try it out and let you know how it worked, thx!
– tApja
Mar 7 at 23:58
Okay now this is interesting, I'm going to try it out and let you know how it worked, thx!
– tApja
Mar 7 at 23:58
1
1
I gave your more details in my answer, thanks good luck!
– Quentin C
Mar 7 at 23:59
I gave your more details in my answer, thanks good luck!
– Quentin C
Mar 7 at 23:59
|
show 2 more comments
I would go with the date validation, but doing it on the client side wouldn't be very safe, because variations in local times could cause users to incorrectly be identified as early or late. To solve that I see two options:
The first one would be creating an HTTPS Cloud Function where you could get the server date and send it to the database. That way you are not influenced by the local date on your users' devices. You could also do the same by hosting this code anywhere you want and calling it with HTTP, the Cloud Function is just easier.
The other option would be first saving the date and the user to Realtime DB. It was created for realtime applications, so it will probably be faster than Firestore to write. You can then create a DB Cloud Function that would get the date and send it to Firestore, and there you can validate which user saved first.
add a comment |
I would go with the date validation, but doing it on the client side wouldn't be very safe, because variations in local times could cause users to incorrectly be identified as early or late. To solve that I see two options:
The first one would be creating an HTTPS Cloud Function where you could get the server date and send it to the database. That way you are not influenced by the local date on your users' devices. You could also do the same by hosting this code anywhere you want and calling it with HTTP, the Cloud Function is just easier.
The other option would be first saving the date and the user to Realtime DB. It was created for realtime applications, so it will probably be faster than Firestore to write. You can then create a DB Cloud Function that would get the date and send it to Firestore, and there you can validate which user saved first.
add a comment |
I would go with the date validation, but doing it on the client side wouldn't be very safe, because variations in local times could cause users to incorrectly be identified as early or late. To solve that I see two options:
The first one would be creating an HTTPS Cloud Function where you could get the server date and send it to the database. That way you are not influenced by the local date on your users' devices. You could also do the same by hosting this code anywhere you want and calling it with HTTP, the Cloud Function is just easier.
The other option would be first saving the date and the user to Realtime DB. It was created for realtime applications, so it will probably be faster than Firestore to write. You can then create a DB Cloud Function that would get the date and send it to Firestore, and there you can validate which user saved first.
I would go with the date validation, but doing it on the client side wouldn't be very safe, because variations in local times could cause users to incorrectly be identified as early or late. To solve that I see two options:
The first one would be creating an HTTPS Cloud Function where you could get the server date and send it to the database. That way you are not influenced by the local date on your users' devices. You could also do the same by hosting this code anywhere you want and calling it with HTTP, the Cloud Function is just easier.
The other option would be first saving the date and the user to Realtime DB. It was created for realtime applications, so it will probably be faster than Firestore to write. You can then create a DB Cloud Function that would get the date and send it to Firestore, and there you can validate which user saved first.
answered Mar 7 at 12:34
Ricardo SmaniaRicardo Smania
1,1081122
1,1081122
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f55043469%2fovercoming-firestore-update-slight-delay%23new-answer', 'question_page');
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown