couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliff Williams <cliffywi...@aol.com>
Subject Re: CouchDB _changes + continuous + Ajax
Date Mon, 27 Dec 2010 14:07:12 GMT
N/A N/A

I took a look at this yesterday.

My assumption is that you are using a web page to display the _changes 
feed delivered from couchdb (probably couchapps).

if this is the case then i do not think that you should be using the 
continuous feed since my belief is that, by design this should be used 
for decoupled systems (I also think that some browsers will struggle 
with it) eg node.js / ruby /python.

What you should be using is the longpoll feed.

I began to write an example but found the perfect thing in jquery.couch.js

the function is changes (an example is worth a thousand words)

note I modded jquery.couch.js at around line 270 from

               feed : "longpoll",
               since : since,
to
              feed : "longpoll",
               since : since,
               include_docs : true

not sure if this is the correct way to do things but did not look too deep.


<code>
<!DOCTYPE html>
<html>
<head>
<title>Couchdb continous feed test</title>
<script src="/_utils/script/jquery.js"></script>
<script src="/_utils/script/jquery.couch.js"></script>
</head>


<script>
var changes = $.couch.db("test").changes();

// Set up multiple callbacks (Nice!!)
   changes.onChange(dbchanges);
   changes.onChange(dbalert);
   changes.onChange(dbrealtime);

// callback code examples for changes feed
// (1) console log
function dbchanges(response) {
     console.log( " Database changes: ", response );
}
// (2) show a field (response is a json object)
function dbalert(response) {
      alert(response.results[0].doc.address);
}
// (3) something more interesting display a real time list of changes
function dbrealtime(response) {
     var now = new Date();
     var month = now.getMonth() + 1;
     var day = now.getDate();
     var year = now.getFullYear();
     var date = day + "/" + month + "/" + year;
     var time = now.getHours() + ":" + now.getMinutes()

     $("#tab1 > tbody:first").append("<tr><td>" + date +"</td><td>"
+ 
time + "</td><td>" + response.results[0].doc.Surname +"</td><td>"
+ 
response.results[0].doc.address +"</td></tr>");
}

</script>

<body>

<h1>Look at jquery.couch.js for changes feed</h1>

<table id=tab1 border="1">
<tr><th>Date</th><th>Time</th><th>Name</th><th>Address</th></tr>
<tbody></tbody>
</table>

</body>
</html>
</code>

best regards

Cliff


On 25/12/10 09:37, Johannes J. Schmidt wrote:
> Hi,
>
> You could check the length of req.responseText and call abort() if it
> exceeds a limit. Or you can check for the number of revs the feed is
> reporting and implement a limit of revs per connection.
>
> Btw. Depending on your application you should query the database info
> object (/dbname) to get the latest seq (update_seq).
>
> Greetings
> Johannes
>
> Am Freitag, den 24.12.2010, 08:14 -0800 schrieb N/A N/A:
>> Hi,
>>
>> Thank you! Hope you are well too...
>>
>> Yes. First i'm doing changes poll without feed, so i can retrieve last_seq
>> key/value. Next i'm doing Ajax request like your with feed, heartbeat and even
>> include_docs.
>> This is working just fine. The code bellow is what i mean. There is function in
>> couch.js "CouchDB.request". I patched it a bit for my needs for continuous
>> _changes read.
>> I can post all of the function code later. But what i mean is this:
>>
>>
>>    var req = CouchDB.newXhr();
>>    if(uri.substr(0, "http://".length) != "http://") {
>>      uri = CouchDB.urlPrefix + uri
>>    }
>>    req.open(method, uri, true);
>>    req.onreadystatechange = function () {
>>        console.log(req.responseText);
>>    }
>>
>> responseText is read only. While the socket is open every
>> time onreadystatechange trigger, it only appends the result. So responseText is
>> growing really big and after N seconds/hours/days maybe ill be out of memory.
>> What to do, so i can avoid this? If something is not clear enough i'll post some
>> code later with some more explanations and logs.
>>
>> Thanks
>>
>>
>>
>> ________________________________
>> From: Cliff Williams<cliffywills@aol.com>
>> To: user@couchdb.apache.org
>> Sent: Fri, December 24, 2010 5:27:18 PM
>> Subject: Re: CouchDB _changes + continuous + Ajax
>>
>> N/A N/A
>>
>> I hope you are well and looking forward to Christmas
>>
>> I am not sure that I fully understand but are you querying using last
>> sequence ?
>>
>> I use
>>
>> changesurl = "http://"+ host +":"+port.tostring+"/"+database+
>> "/_changes?feed=continuous&include_docs=true&heartbeat=10000
>> +"&since="+lastseq",
>>
>>
>> I can let you have a copy of a skeleton node.js program that I use if
>> you think that it would help.
>>
>> best regards
>>
>> cliff
>>
>>
>> On 24/12/10 14:04, N/A N/A wrote:
>>> Hi there,
>>>
>>> I am trying to use continuous changes of CouchDB + some java script. Using
>>> couch.js, because it is nice and clean template for experiments i manage to
>>> establish a connection to CouchDB and my webapp. Everything is working fine
>>> except one thing. Because the socket is still open, my responseText in ajax is
>>> just appending the JSON answers, so it is getting bigger and bigger and
>> bigger.
>>> With heartbeat of 100, memory usage is growing pretty fast. JSON data transfer
>>> could be really high sometimes and dataloss is not an option for me. One
>>> solution for me was just to use websocket + node.js(or similar). Or maybe to
>>> split() the answer in array and when it reach certain length to reopen the
>>> socket with current sequence of _changes. But this solution is not for my
>> taste
>>> and looks for me like a hack and not like solution. So, if someone is familiar
>>> with continuous changes, is it possible to give me some advice how we can use
>>> continuous changes + ajax without responseText getting so big? Any workaround
>> ?
>>> I prefer to not use websocket stuff(or something), because i prefer to keep
>>> things clean and stick only with CouchDB.
>>>
>>> Thanks in advance
>>>
>>>
>>>
>>>
>>
>>
>>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message