I'm using firebaseui, and it has the signInSuccessWithAuthResult callback which returns me the user.
So inside of there I want to call back out to a firestore document where I have more user profile data to use and save.
But I think this method is completing before the firestore .get() is and just never works.
Am I thinking about this problem wrong? Is this just not the right place to do this?
But I think this method is completing before the Firestore .get() is and just never works.
You are guessing right, the operation of adding a listener is asynchronous and returns immediately and the callback from the Task it returns will be called sometime later. There are no guarantees about how long it will take. Depending on your connection speed and the state, it may take from a few hundred milliseconds to a few seconds before the authentication process is complete.
If you want to use the results of your authentication process, you must wait until the asynchronous operation is complete. This means that you can only use the results inside the listener callback itself.
Related
if you see here https://firebase.google.com/docs/firestore/solutions/delete-collections
you can see the below
Consistency - the code above deletes documents one at a time. If you
query while there is an ongoing delete operation, your results may
reflect a partially complete state where only some targeted documents
are deleted. There is also no guarantee that the delete operations
will succeed or fail uniformly, so be prepared to handle cases of
partial deletion.
so how to handle this correctly?
this means "preventing users from accessing this collection while deletion is in progress?"
or "If the work is stopped by accessing the collection in the middle, is it to call the function again from the failed part to proceed with the complete deletion?"
so how to handle this correctly?
It's suggesting that you should check for failures, and retry until there are no documents remaining (or at least until you are satisfied with the result).
I am trying to use flux with firebase, and found out that the Firebase.on() callbacks are sometimes triggered synchronously by a Firebase.set() called within the same client.
This does not jive with the flux pattern of dispatching an action when the user triggers a firebase set and another one when the value comes back, which will break the multiple dispatch invariant.
A workaround would be to delay the mutation calls with process.nextTick(). Is there a way to force the callbacks to be called in the next tick instead, like how promises work? Or is there a recommended pattern here?
I have successfuly saved the state machine and applied bookmarks to state machine after loading them for mutiple times.
But what happens when they reach to a final state ?
Why they are removed from persitance data store ([System.Activities.DurableInstancing].[InstancesTable]) after geting finished?
Is that normal or am I makeing a mistake in persisting finished statemachines ?
Workflow is code. You define the logic using larger pieces, but it executes and returns a result. It is not the result itself.
Imagine you had a class that had methods you call that determines approval/denial. You would spin up that class, pass in argument values, and let the code execution determine approval/denial. What do you do after this code executes?
You wouldn't store the code of that method, that's for sure. You would store who approved, who denied, and the final result.
So you shouldn't be storing the code of the workflow but the results.
I would accomplish the goals of this workflow by creating custom Activities extending NativeActivity, using one or more workflow extensions to communicate with the outside world to send notifications about approval or denials waiting for action. Along the way I'd record who did what when my bookmarks resume execution. When the workflow completes, I record the final result as well.
My ASP.NET (3.5) app allows users to run some complex queries that can take up to 4 minutes to return results.
When I'm doing a long loops of code, I'll check Response.IsClientConnected() occasionally so I can end the page if the user closes their browser or hits the stop button.
But when querying SQL Server, my .NET code is blocked at the call to GetDataReader().
Is there a straightforward way to do GetDataReader() asynchronously so I can wait around for it but still check, say, every 5-10 seconds to see if the user is still connected, and bail on the database query if they've left?
Or is there some other alternative I'm not thinking of?
you can use the sqlcommand's BeginExecuteReader to get an asynch sqlreader
example
not 100% sure if thats what you need?
link showing cancel
I would suggest creating an object that has Start() and Wait() methods encapsulating your query. Internally use a ManualResetEvent to wait on the query completing. You'll use the Set() function when the query is complete, and the WaitOne() or WaitOne(TimeSpan ts) method to wait on it in your Wait() method.
Is it generally fast enough to make simple updates synchronously? For instance with a ASP.NET web app, if I change the person's name... will I have any issues just updating the index synchronously as part of the "Save" mechanism?
OR is the only safe way to have some other asynchronous process to make the index updates?
We do updates both synchronous and asynchronously depending on the kind of action the user is doing. We have implemented the synchronous indexing in a way where we use the asynchronous code and just waits for some time for its completion. We only wait for 2 seconds which means that if it takes longer then the user will not see the update but normally the user will.
We configured logging in a way so we would get notified whenever the "synchronous" indexing took longer than we waited to get an idea of how often it would happen. We hardly ever get over the 2 second limit.
If you are using full text session, then you don't need to update indexs explicitly. Full text session take care of indexing updated entity.