Just wondering about the best way to subscribe to my CouchDB data store, so that if a document in couch is updated, the KO view will also update (automagically). Is this something that's even possible?
Below is what I have so far, which simply get the user name from the user_info document.
$.getJSON('http://localhost/couchdb/user_info', function(data) {
var viewModel = ko.mapping.fromJS(data);
ko.applyBindings(viewModel);
});
Any help would be greatly appreciated!
CouchDB supports notifications when documents change: the changes feed.
You can poll the changes feed, with a ?since=X parameter to receive only updates since X.
You can also "long poll" the feed by adding &feed=longpoll. If there are no changes yet, CouchDB will receive your query but not answer until finally a change comes on.
Or, you can have a full COMET-style feed by instead adding &feed=continuous. That is similar to longpoll, however CouchDB will never close the connection. Every time a change happens, it will send you the JSON and then continue waiting.
Finally, you can be notified when anything changes in the database, or you can specify a Javascript filter to run on the server (&filter=designdoc/filtername). You will only receive notifications if the filter approves.
Have you looked at http://hood.ie/ it woks well. I'm also running hoodie as an os_daemons service from within my couchdb.
It's nice.
Related
I am trying to build a web app where users can receive notifications if their posts get likes. This functionality is actually working but the notification component renders only when the page reloads. But I want it to re-render the notification component as soon as there is a change that occurs with it. I am trying to make this work with SocketIO both in client and server but it feels like there should be a way easier way to solve this issue. How?
One way to achieve this is to use server-sent events (SSE), which can be seen as a uni-directional
and simplified version of WebSocket (only server can send data to clients). You might need route param or query string so that users can connect to different channels.
If it doesn't have to be so real-time (i.e. receiving notifications 1 minute after somebody liked the post is okay), you could also try (long)polling.
However, since post-like table may contain a huge amount of data, constantly querying it is expected to result in bad performance on the server. Also, adding an extra column to mark if the user has been notified about a specific like is trivial.
A possible workaround might be to create a new table, say pending-like-notification, which is used to stored all pending like notifications. Whenever a post is liked, we insert a new record into this table.
Therefore, when a user tries to query if any of his posts is liked recently, in the backend we lookup this table instead of the post-like table, and delete the selected rows after the user has been notified so that the amount of data in this table can stay low (hopefully).
All in all, in this scenario, I think SSE and WebSocket will be better choices.
currently i'am developing a react app where user can post and comment and like a post.
so i did everything but there is one more thing that i want to do which is getting notification after user
Post or maybe comment and so on..
so let say i have a table called 'posts' in the database (PostgreSQL) and when user called "A" create post ,that post inserted into the database and then i want to receive a notification which Said that the user "A" created a post with the ID of that post and i think the main idea here is to watch the table of posts and whenever a new raw inserted a notification fire.
i searched many sources and find that i can use Pusher ,web-socket but to be honest i can't make a decision without figuring out the best way to achieve that.
So How i can get notified hence a new row inserted into the table "posts" ?
Thank you in advance.
Postgres has LISTEN/NOTIFY that you could use in conjunction with an on-insert trigger on the posts table.
Some process can then be listening for those notifications and figure out whom to send the notification to (via whichever transport you choose).
However, I think you might be better off adding a concrete table for notifications, so the user can see notifications that occurred when they weren't connected to the notification transport.
I have a realtime app where users are clicking on a button at the exact same time. It is a rideshare app where a ride will show up on all the users's screens, and then 2 users will basically simultaneously push the "accept ride" button. This creates problems because it saves the first user onto the ride via a database save call, but then the second user oversaves the first user. Once a user accepts the ride, another user should not be able to accept the ride. It creates major problems because the first user should just "accept the ride" while, with the second driver, it should just tell them "another driver is accepting the ride". The problem is that I can not even run a query to check if the ride already has a driver because this is all happening so quickly. The first user will hit "accept ride", then it will save them to the ride. The second user will hit "accept ride", and it will check if the ride already has a driver. It doesn't yet because the first save is still finishing. Then the second user is oversaved on the ride. It just is happening way to simultaneously where queries don't really solve the problem.
Sorry if this is a confusing explanation. I have never had to deal with this realtime of a problem, so I am not sure where to start. I think I need to build some queue or something that only lets this happen once at a time. Any direction of what to even google would be helpful. Thank you! My backend is written in node.js and I use MongoDB on Heroku.
You need an atomic check and set operation in your database so in one atomic database operation, you can verify that it's not already accepted and, if not, accept it. That will only allow one person to accept it, any others will fail because it's already accepted and the API can feed that back to the user interface. The key word here is "atomic" and how you achieve it depends upon the specific database. For MongoDB, see Mongo any way to do atomic check and set.
Here's another reference: Help writing an atomic update in mongodb.
These solutions use mongodb's findandmodify so presumably, you would attempt to find a document with this id and that is also not accepted and if found, you would modify it to be accepted. Then, since the findandmodify is atomic, nobody else can get in between your find and your modify so when their findandmodify gets a turn, they won't find a document that is both the right id and is not accepted because someone else accepted it before they got in.
I am trying "update handlers" to catch create/update/delete events in IBM cloudant. It works when a document is created or updated, but not deleted. Is there any other way I can catch an event that a document is deleted and then create a document in another database to record this event? Thank you.
If you want to monitor a couchDB/Cloudant database for changes take a look at the /_changes feed: http://docs.couchdb.org/en/2.0.0/api/database/changes.html. You could implement an app that continuously monitors the feed and "logs" the desired information whenever a document is inserted, updated or deleted. For some programming languages there are libraries (such as https://www.npmjs.com/package/follow for Node.js) that make it easy to manage/process the feed.
I have a mobile app using Couchbase lite. When the user logouts, I want to remove some of the documents on the device; the user-specific documents. I do not want to remove all of the documents. Documents have a purgeDocument() method that I thought I could call on those user-specific documents.
The problem is that the purged documents are not re-synced down to the device if the user logs back in and a pull replication is run.
Based on the little I know of CouchDB sync protocol, it makes sense that those are not re-synced down because there are not newer Sequence updates on those user-specific documents to trigger a re-sync.
How should I approach this problem?
Possibilities
Delete the whole database (including common documents) and lose performance.
Somehow reset the last sequence for the replicator and hope the replicator does not transfer the already-downloaded docs over the wire. (Probably would screw up CBL)
Have separate databases, one that stores the user-specific docs and one that contains common docs. Databases can have filtered replicators (by channel) so it would be feasible to partition the incoming data into separate databases. The problem would be the seamless reference loading between documents of differing databases when using CBLModel objects wrappers.
As i understand from the official documentation in the subsection Purging documents, you are not retrieving the document again just because it has not been modified/updated (in short, its rev is the same) on the server side.
You can try to create again a dummy document with the same type and, for example, username (or whatever you are using to identify the user's configuration) when the user logs again in your app so that you trigger the pull replication from the server. You probably will have a conflict that can easily be solved taking the revision from the server.
I hope this idea helps a little.
UPDATE AFTER COMMENT
The idea is to store somewhere the id and type of the user's documents you're going to purge. That way you can create a new dummy document with those two fields when the user logs in again. Perhaps this new dummy document triggers the pull replication.
NOTE: I haven't tried this method. I am just guessing what it might be a work around to your problem.
I would suggest that your backend modifies the selected documents - this could be just a timestamp update - upon user login, which will post the new revisions to the device
You can keep purging the documents when the user logs in.
To solve problem of re-syncing specific document, I think the easiest way is to use filtered replication where the filter is document id.
These document IDs can be created in a manner which can be derived. For example it can be as UserDocument::.
Now when the user logs in you can start one shot replication with document ID as filter. This can only be done in one shot. And when this One Shot finishes you can start replication again by changing the setting of the replication(changing filter/channel).
following is the URL by Couchbase which explains filtered replication by document ID.
https://developer.couchbase.com/documentation/mobile/1.4/guides/couchbase-lite/native-api/replication/index.html#filtering-by-document-ids
Try Push after Purging the document with Couchbase Lite which allows you to Pull the document from the server at a later point.