Can pouch db js be configured to talk directly to a remote CouchDB server?

[Colin]

When my site has network connectivity, I may want to connect my users directly to my couch server rather than using local storage. The Pouch API documentation for the Pouch constructor implies that I should be able to use the Pouch js as a pass through to my CouchDB server in this case. It says "The protocol field denotes which backend you want to use (currently only http and indexeddb are supported)." This makes me think I should be able to do this:

Pouch("http://localhost:5984/myAppDB", function(err, db ){ 

   function map(doc) { emit(doc._id, doc);}

  db.query({map: map}, {reduce: false}, function(err, response) {

     console.log(JSON.stringify(response));

  })

})

And get back my documents directly from my CouchDB instance rather than from indexedDB, but it doesn't work. Am I doing something wrong?

I get this when I try that:

Uncaught TypeError: Object #<Object> has no method 'split' pouch.alpha.js:1119

[Dale Harvey]

Hey Colin

2 issues here, One is that CouchDB doesnt currently support cors, which means unless you are serving the pouchdb website from the same domain as CouchDB, or using a proxy, it cant communicate

https://github.com/daleharvey/pouchdb/issues/25

The other is that I havent implemented _temp_views in the http client

https://github.com/daleharvey/pouchdb/issues/98

Normal design docs sourced views should work fine

Thanks

Dale

--
You received this message because you are subscribed to the Google Groups "PouchDB" group.
To post to this group, send email to pou...@googlegroups.com.
To unsubscribe from this group, send email to pouchdb+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msg/pouchdb/-/HOyzOxOupeUJ.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Colin]

OK, got it. Thanks. I'm fine on the first point because I'm serving this from CouchDB.

The second point is my problem because I'm trying to call a temp view over http. So, if I implement a "real" view in my app's design document and then call that one from Pouch, it should work. It will be a little tricky because when hitting idb I will have to use temp views but when hitting the server over http I will have to used "designed" views.

I think this is convincing me that I should not go down this road and should instead always interact with idb and then just replicate to get my data back and forth. You agree?

[Dale Harvey]

If you use a design doc, it will work over both http and idb in pouch, as long as both sources have the design doc.

One of Pouch's goals is to be transparent to what backend is storing your data, so I will be implementing temp views which will work on both http and idb backends, the reason they havent been implemented up until now is that you are highly recommended against using them in CouchDB itself (whereas in PouchDB there is no difference)

Thanks

Dale

--

You received this message because you are subscribed to the Google Groups "PouchDB" group.
To post to this group, send email to pou...@googlegroups.com.
To unsubscribe from this group, send email to pouchdb+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msg/pouchdb/-/x3yj-k2atj0J.

[Colin]

Thanks Dale. This makes sense.

What's the recommended way for getting my design doc views into my local PouchDB instance? I know how to deploy a view as part of my couchapp on the server side, but I'm not sure how to get the view design down to the client. I've tried simply replicating my database but that doesn't seem to do the trick. Do I need to replicate in a special way to get the design docs to come along with the regular docs? Or, maybe the problem is that I just don't know how to properly reference the view.

I've tried both this:

db.query('_view/myViewName', {reduce: false}, function(err, response) {

and this:

db.query('myAppName/myViewName ', {reduce: false}, function(err, response) { //this one looks just like your test code you referenced on github.

but I'm just getting 404 back, which makes me think my view is not in my PouchDB.

[Colin]

I figured out how to do this. Tell me if this is correct:

1. Define a view in CouchDB (server side).

2. Replicate from CouchDB to PouchDB. This brings the view design into the local PouchDB inside my browser.

3. In my local js, do this: db.query('myAppName/myViewName ' ... to execute the view.

4. This works for me when using idb:// against local data and when using http:// against the server side data. I can just change my datasource when I connect: Pouch(datasource...).

Is this the expected use case? In other words:

1. Create a couchapp, including views, and deploy it to CouchDB.

2. Replicate that db to a PouchDB instance.

3. Consume views on the client using db.query.

What's a little weird (to me) is that my "code" comes down to the browser in 2 different ways. Some of it comes via a regular http get from the browser just getting the html and js from the server (which I then cache using html5 appcache manifest), while the views (which are really more code) come down using replication. I guess if I don't like that I can just use temp views against idb, which perform the same anyway and just use replication for data.

Thanks for any confirmation / opinion / comments.

Colin

[Dale Harvey]

Yup thats a perfectly valid workflow

You have highlighted to me that it can be problematic to define design docs inside PouchDB though, There has already been plans to create a design doc editors along the lines of futon that can administer and define / edit design docs for both pouchdb + couchdb

Another nice feature would be to drag and drop an existing 'couchapp' folder into that admin panel to import a design doc.

If you have any other input into how you would like your workflow to go that would be great, these parts are still very much in infancy, the couchapp method has always been problematic in CouchDB, so having a solution that worked better for both Couch + Pouch would be great

Cheers
Dale

--

You received this message because you are subscribed to the Google Groups "PouchDB" group.
To post to this group, send email to pou...@googlegroups.com.
To unsubscribe from this group, send email to pouchdb+u...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msg/pouchdb/-/-FIYHsDzSsoJ.

[Colin]

Here's what trips me up: I'm trying to build a web app that can work disconnected, then replicate its JSON data to a server, (perfect for Pouch/Couch). I create my app as HTML/js that is served from CouchDB and cached locally using HTML5 AppCache. I replicate all my JSON data using Pouch/Couch replication. Great!, except views, which are mixed in with the JSON data replication. This is bad because views are part of my application logic. When I release a new version of the HTML/js that relies on some new view, I have no way of knowing if the new view will replicate down to PouchDB before or after my HTML/js is updated in the HTML5 AppCache. My app will then be broken because it will need a view that's not there.

The cause of this problem is that I'm using these 2 different delivery mechanisms: AppCache for code (_design) and replication for JSON docs, whereas the normal use case for Couchy stuff is that everything should come via replication and get served directly from CouchDB. That's what I'd do if I were making a standalone app with CouchDB deployed on the client right?

So, maybe that same "everything should replicate" answer should apply for PouchDB as well. In other words, maybe my _design doc should come down to PouchDB and my web browser should "run" that instead of loading the _design from the server and using AppCache to hold it locally. Problem is that I don't know how to do that. Is it possible to point my client web browser at an HTML page that is served from within PouchDB? I don't think it is. I could create a simple HTML/js stub to get _design contents out of PouchDB and show them in my browser, but relative links within that content would not work because the web browser would try to get those from relative locations that don't really exist.

I know that PouchDB is intended to fully impersonate CouchDB and this last step of actually delivering a _design would do that. If that could be done, then we could have Futon sitting there in PouchDB as well couldn't we?

Am I making sense?

[Colin]

I should add that a different (much simpler) solution for this is for me to simply use temp views that I define within my html/js code, thereby guaranteeing they are delivered/cached along with my code. Since PouchDB is really only doing temp views anyway, the performance is the same as using a "real" view.

Do any of these same concepts apply for Shows and Lists? Does PouchDB support Shows / Lists at all?

[Ryan Mohr]

Just to clarify on this one...

If a design doc is used and we're working over http then the standard couchdb view will be used.  If we then switch to pouch/idb the behavior will be identical but the queries will likely be much slower.

Correct?

[Dale Harvey]

Yup, thats right

https://github.com/daleharvey/pouchdb/issues/99 is where we are tracking incremental views, it may be getting worked on soon

To unsubscribe from this group and stop receiving emails from it, send an email to pouchdb+u...@googlegroups.com.

To post to this group, send email to pou...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msg/pouchdb/-/G0V183tKOjwJ.

[William Edney]

FYI to a point made earlier in this thread, CouchDB 1.3 will have CORS support:

http://wiki.apache.org/couchdb/CORS

Cheers,

- Bill