I'm new to Meteor. I intend to add a new document to collection(client+server) and let the server pick the change. Then when i need to update my template with the sum total of all the inserts/updates/removes on the collection, i publish the collection from server and subscribe to it on client.
Once we publish something, can we subscribe, stop subscription and then subscribe again? I intend to subscribe only when the 'add document' button on client is pressed. In the function that processes such a click, I intend to insert, then call the method on server to publish and then subscribe. Is that a proper way of going about this?
Is there a way to simplify this? like i put the insert or update of a document in to the client side collection and just let Meteor deal with updating the server side collection and then updating the client side template?
It appears to me, from what little I learnt, that for some use-cases that I have, need publishing at each click. I've done this to update the reactive table to list the current folder's contents each time a folder is selected. So a Publish on server checks for contents in the collection for that folder as parent and returns it. Each new select of a folder means new publish. Can something be done to simplify this?
You're overcomplicating one of the core concepts behind Meteor: reactivity. Here are some clarifications to your 3 questions though:
This isn't something you need to worry about. Once you publish a
collection, or subset of your collection, it's published to all
connected clients. When you're subscribed to said publication, any
updates that are made are reactively pulled down to all connected
clients with that subscription. So if I add a document to a
collection I'm subscribed to, say a task list, it's going to be
reactively sent down to any client that's subscribed to it,
including my own.
Meteor has something called latency compensation which immediately
updates the user interface, and as long as it matches what the
server says, the insert appears to happen instantaneously. This
behavior is what Meteor does by default if you insert to a
collection from the client, as long as your insert is approved (i.e.
as long as the client has permissions to insert to that collection).
You don't need to republish every time. As long as you're publishing
the documents in the collection you need, and you're subscribed on
the client, any new documents that meet the criteria of your Mongo
selectors and return statements on the client will be available to
you and your UI will be updated automatically.
Related
I know it's not possible to update an array within a document directly in Firestore by index, and you have to do it on the client side.
What happens when you have multiple concurrent users writing to the array of the particular document? How do we ensure that the updates to an array is made on the latest version of the document?
For example, when user A queries the document on the client side to update the array, there might have been an new update to the array made by user B that took place shortly after the query took place. Now if user A updates that array, it will be on an old version of the document, and if user A writes back to the database it will essentially overwrite user B's updates...
How can this be handled?
If you want to protect against concurrent writes, use a transaction. They protect against the scenario you describe by performing a compare-and-set (in the case of the client-side SDKs) or a lock (in the case of the Admin SDKs).
I enabled Persistence on my Firebase project for Firestore.
I am getting the documents of a user via a simple call.
this.afs
.collection('users')
.doc(user.uid)
.collection("events").snapshotChanges().subscribe(...etc etc...)
The above call is fed to an Angular table DataSource
Perhaps the above do not matter so much but just making sure.
To the point.
The list I am getting back for the collection events contains items that are possibly deleted when the Firestore Persistence is enabled.
I crosschecked the IDS that persistence gives and some do not exist in the online DB.
I am not sure why/how this has happened but I am a bit confused in regards to:
Am I doing something wrong?
Should I be making some different call?
Is this a bug?
When you attach a listener to snapshotChanges() it immediately queries the local cache, and satisfies the query from that. It then connects to the server, to check for any updates. If there are any updates, it will fire snapshotChanges() again with the updated snapshot (and update the local cache from that).
So it is indeed possible that you get stale data in the first callback for snapshotChanges().
But usually you'll just update your UI from snapshotChanges(), and so you'd again update the UI once the second (up to date) data comes in.
I am using the "low-level" publication API to publish a temporary collection (not backed by MongoDB).
The published collection is an homemade aggregation which depends on various persistent collections.
Due to business logic, at some point when I want to clear the published collection. This would mean calling this.removed('my-collection', id) for every item in the collection. However I don't want to maintain the list of item in the collection (this would probably be redundant with internal meteor cache anyway).
Is there a simple way to clear a collection from the server's publish code?
I have a form which collects some information from logged in user. I am able to store collected data in a collection and display it to user. I want to show a preview of collected data and ask him for confirmation before that gets published to all other clients or users.
please suggest the way to do so.I saw the Meteor.pulish() in docs but not able understand how to use it.
Meteor.publish does something different, and works on server-side. Please read this to understand how to use Meteor.publish, collections and subscriptions.
What you want to do needs to be done client-side, with the values from the form, before you insert them in the collection; that's because once you do the collection.insert, meteor will send the record to the server, which will publish it to all other clients.
We are implementing Signalr to provide real time updates to browser clients. But we are curretnly stuck as we need to make http server itself (IIS+ASP) detect the changes from database and external services or from any other source without polling?
I believe this should be a common problem with all real time websites (irrespective of what technology is used for server side push SignalR, Comet or WebSync). Please provide what are general approaches used in such situations?
If you can, raise an event in whatever code is updating your database. Use that event to trigger the message publication.
Ready to update database -> Update database
-> Publish to WebSync
If you can't control the code updating your database, use the SqlDependency class. It lets you define a SELECT statement and then notifies you whenever the results of that query change. Use the notification event to trigger the message publication.
Update database -> SqlDependency -> Publish to WebSync