I'd like to see something like the jira-486: some refactoring of the internals, better separation of concerns, etc.. the idea being to enable hackers who wish to extend the capabilities of the internals in a somewhat principled way. I think the code base is at the size (~15K lines in src/couchdb) now where it's still manageable but it's increasingly difficult to understand all the pieces in any depth given the functionality packed into it. I know there's been lots of discussion around this on irc, etc.. it strikes me that the time is right to put a stake in the ground on it. Cheer, Bob On Dec 3, 2009, at 2:29 PM, Noah Slater wrote: > Hey, > > As part of the release procedure, this is a request to update the roadmap document: > > http://couchdb.apache.org/roadmap.html > > Please comment on what should be added, and what should be removed. > > After a we reach consensus, I will update the roadmap. > > Thanks, > > Noah
[ https://issues.apache.org/jira/browse/COUCHDB-583?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Filipe Manana updated COUCHDB-583:
----------------------------------
Attachment: couchdb-583-trunk-3rd-try.patch
Hello,
Here follows the patch implementing Damien's suggestion.
A new key under the httpd section is added to the config file. Its value is the name of a
file that lists which MIME types are worth compressing (text based types for e.g.).
When an attachment is uploaded (using the standalone attachment API), if its type matches
one of the MIME types listed in the former file, the attachment is stored with gzip compression.
When a client requests the download of an attachment:
1) if the HTTP request message has an Accept-Encoding header listing gzip as an acceptable
response body encoding method, the attachment is sent unmodified to the client (in gzip form
and in a chunked HTTP message)
2) if the HTTP request doesn't include that header, or if it includes but it mentions gzip
as not acceptable, the attachment is uncompressed (on the fly) and sent to the client (in
a chunked HTTP response)
An Etap test, covering 7 scenarios, is included.
Note that it breaks some other tests (for example, tests that upload a text attachment and
then downloaded it to check its content). I'll fix those tests after your feedback. This is
a preliminary version.
Feedback (specially from the commiters) regarding the implementation is very welcome.
cheers,
Filipe Manana (fdmanana)
> adding ?compression=(gzip|deflate) optional parameter to the attachment download API
> ------------------------------------------------------------------------------------
>
> Key: COUCHDB-583
> URL: https://issues.apache.org/jira/browse/COUCHDB-583
> Project: CouchDB
> Issue Type: New Feature
> Components: HTTP Interface
> Environment: CouchDB trunk revision 885240
> Reporter: Filipe Manana
> Attachments: couchdb-583-trunk-3rd-try.patch, jira-couchdb-583-1st-try-trunk.patch,
jira-couchdb-583-2nd-try-trunk.patch
>
> Original Estimate: 24h
> Remaining Estimate: 24h
>
> The following new feature is added in the patch following this ticket creation.
> A new optional http query parameter "compression" is added to the attachments API.
> This parameter can have one of the values: "gzip" or "deflate".
> When asking for an attachment (GET http request), if the query parameter "compression"
is found, CouchDB will send the attachment compressed to the client (and sets the header Content-Encoding
with gzip or deflate).
> Further, it adds a new config option "treshold_for_chunking_comp_responses" (httpd section)
that specifies an attachment length threshold. If an attachment has a length >= than this
threshold, the http response will be chunked (besides compressed).
> Note that using non chunked compressed body responses requires storing all the compressed
blocks in memory and then sending each one to the client. This is a necessary "evil", as we
only know the length of the compressed body after compressing all the body, and we need to
set the "Content-Length" header for non chunked responses. By sending chunked responses, we
can send each compressed block immediately, without accumulating all of them in memory.
> Examples:
> $ curl http://localhost:5984/testdb/testdoc1/readme.txt?compression=gzip
> $ curl http://localhost:5984/testdb/testdoc1/readme.txt?compression=deflate
> $ curl http://localhost:5984/testdb/testdoc1/readme.txt # attachment will not be compressed
> $ curl http://localhost:5984/testdb/testdoc1/readme.txt?compression=rar # will give
a 500 error code
> Etap test case included.
> Feedback would be very welcome.
> cheers
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Quoting Noah Slater <nslater@tumbolia.org>: > As part of the release procedure, this is a request to update the > roadmap document: > Please comment on what should be added, and what should be removed. What I would like to see is "map/reduce chaining", as this really would blow away most limitations currently imposed by couchdb. A good example for this would be "get the 10 most popular items from a tag cloud". Of course, this also might affect efficiency, as every layer of map/reducing imposes housekeeping and update costs. Cheers, Kosta
[ https://issues.apache.org/jira/browse/COUCHDB-594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adam Kocoloski closed COUCHDB-594.
----------------------------------
Resolution: Fixed
fixed in r888267 (trunk), r888268 (0.10.x)
> Replicator does not release old Fd of compacted DB
> --------------------------------------------------
>
> Key: COUCHDB-594
> URL: https://issues.apache.org/jira/browse/COUCHDB-594
> Project: CouchDB
> Issue Type: Bug
> Components: Replication
> Affects Versions: 0.10.1, 0.11
> Reporter: Adam Kocoloski
> Assignee: Adam Kocoloski
> Fix For: 0.10.2, 0.11
>
>
> If you compact a local DB while a replication using that DB is running, the replicator
will hang onto the Fd of the old file forever. Patch is on the way.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Replicator does not release old Fd of compacted DB
--------------------------------------------------
Key: COUCHDB-594
URL: https://issues.apache.org/jira/browse/COUCHDB-594
Project: CouchDB
Issue Type: Bug
Components: Replication
Affects Versions: 0.10.1, 0.11
Reporter: Adam Kocoloski
Assignee: Adam Kocoloski
Fix For: 0.10.2, 0.11
If you compact a local DB while a replication using that DB is running, the replicator will
hang onto the Fd of the old file forever. Patch is on the way.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris Anderson wrote: >> Read-only - of course you could add state to the object if you wanted >> but it'd be cleared when the os process is restarted, which will >> happen from time to time. Of course the next feature request would be to make it possible to sync changes back to the DB :-) [No, I am not asking for that. Yet.] >> The big challenge here is striking the right balance. I'd like to have >> the whole ddoc available to the map and reduce functions, but I don't >> want to invalidate the indexes every time someone changes a show or or >> list. I'll probably end up special-casing the views not to change >> invalidation strategies for now. You could probably make view compaction be a trigger. For example if I was storing functions elsewhere in the design doc and changed them but not the view code using them then you'd have no way of knowing that change mattered. I'd be happy to do a view compaction or something similar to indicate that what is currently stored is out of date. Roger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkscjSAACgkQmOOfHg372QS/kgCfVPiLdDFf1zVCfU6GjXBXZ976 dz0An37mVc49grp/RfR8l73XhR4LoBb+ =umbb -----END PGP SIGNATURE-----
On Sat, Dec 5, 2009 at 11:37 PM, Roger Binns <rogerb@rogerbinns.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Chris Anderson wrote: >>> I'm inclined to agree with you. I'm working on a patch to make it so >>> the show and list funs have access to the entire design document. This >>> should facilitate what you are asking for. > > Would that also have the side effect of not needing the !code macros any > more since you could just grab other functions directly out of the design doc? > yes. > I had been considering plugging the Google Closure Javascript > optimizer/recompiler into my couchapp equivalent. Of particular interest is > its ability to remove unused code which is typical when using libraries. > > http://code.google.com/closure/compiler/ > > Also would the design document access be read-only or read-write? > Read-only - of course you could add state to the object if you wanted but it'd be cleared when the os process is restarted, which will happen from time to time. The big challenge here is striking the right balance. I'd like to have the whole ddoc available to the map and reduce functions, but I don't want to invalidate the indexes every time someone changes a show or or list. I'll probably end up special-casing the views not to change invalidation strategies for now. Chris > Roger > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAksbX0EACgkQmOOfHg372QQiAgCeMsH2vDffZ0gvN+g8Gru/QkvW > LnAAoJeOuDuSLV37ysZO/8Ac688ffEYY > =Q/Os > -----END PGP SIGNATURE----- > > -- Chris Anderson http://jchrisa.net http://couch.io
[ https://issues.apache.org/jira/browse/COUCHDB-593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Anderson closed COUCHDB-593.
----------------------------------
Resolution: Fixed
fixed in r887791,
thanks Roger for the ticket!
> Show returning zero length string results in scary errors
> ---------------------------------------------------------
>
> Key: COUCHDB-593
> URL: https://issues.apache.org/jira/browse/COUCHDB-593
> Project: CouchDB
> Issue Type: Bug
> Components: JavaScript View Server
> Affects Versions: 0.10
> Environment: Ubuntu 9.10
> Reporter: Roger Binns
> Assignee: Chris Anderson
>
> If your show function returns a zero length string then several scary things happen.
Arguably the empty length string should just be returned to the browser.
> function (doc,req) { return "";}
> On returning the zero length string, the following is displayed in the browser:
> {ret_proc,{proc,<0.79.0>,<<\"javascript\">>,\n
{couch_os_process,prompt},\n {couch_os_process,set_timeout},\n
{couch_os_process,stop}}}]}"}
> The following is in the CouchDB log:
> [Sun, 06 Dec 2009 22:10:15 GMT] [error] [<0.64.0>] OS Process Error :: {render_error,<<"undefined
response from show function">>}
> [Sun, 06 Dec 2009 22:10:15 GMT] [error] [<0.53.0>] {error_report,<0.24.0>,
> {<0.53.0>,supervisor_report,
> [{supervisor,{local,couch_secondary_services}},
> {errorContext,child_terminated},
> {reason,normal},
> {offender,[{pid,<0.58.0>},
> {name,query_servers},
> {mfa,{couch_query_servers,start_link,[]}},
> {restart_type,permanent},
> {shutdown,brutal_kill},
> {child_type,worker}]}]}}
> [Sun, 06 Dec 2009 22:10:15 GMT] [error] [<0.64.0>] Uncaught error in HTTP request:
{exit,
> {normal,
> {gen_server,call,
> [couch_query_servers,
> {ret_proc,
> {proc,<0.79.0>,<<"javascript">>,
> {couch_os_process,prompt},
> {couch_os_process,set_timeout},
> {couch_os_process,stop}}}]}}}
> [Sun, 06 Dec 2009 22:10:15 GMT] [info] [<0.64.0>] Stacktrace: [{gen_server,call,2},
> {couch_query_servers,ret_os_process,1},
> {couch_query_servers,render_doc_show,6},
> {couch_httpd_show,'-send_doc_show_response/6-fun-0-',6},
> {couch_httpd_db,do_db_req,2},
> {couch_httpd,handle_request,5},
> {mochiweb_http,headers,5},
> {proc_lib,init_p_do_apply,3}]
> [Sun, 06 Dec 2009 22:10:15 GMT] [info] [<0.64.0>] 127.0.0.1 - - 'GET' /r/_design/rofroks/_show/index
500
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/COUCHDB-593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Anderson reassigned COUCHDB-593:
--------------------------------------
Assignee: Chris Anderson
> Show returning zero length string results in scary errors
> ---------------------------------------------------------
>
> Key: COUCHDB-593
> URL: https://issues.apache.org/jira/browse/COUCHDB-593
> Project: CouchDB
> Issue Type: Bug
> Components: JavaScript View Server
> Affects Versions: 0.10
> Environment: Ubuntu 9.10
> Reporter: Roger Binns
> Assignee: Chris Anderson
>
> If your show function returns a zero length string then several scary things happen.
Arguably the empty length string should just be returned to the browser.
> function (doc,req) { return "";}
> On returning the zero length string, the following is displayed in the browser:
> {ret_proc,{proc,<0.79.0>,<<\"javascript\">>,\n
{couch_os_process,prompt},\n {couch_os_process,set_timeout},\n
{couch_os_process,stop}}}]}"}
> The following is in the CouchDB log:
> [Sun, 06 Dec 2009 22:10:15 GMT] [error] [<0.64.0>] OS Process Error :: {render_error,<<"undefined
response from show function">>}
> [Sun, 06 Dec 2009 22:10:15 GMT] [error] [<0.53.0>] {error_report,<0.24.0>,
> {<0.53.0>,supervisor_report,
> [{supervisor,{local,couch_secondary_services}},
> {errorContext,child_terminated},
> {reason,normal},
> {offender,[{pid,<0.58.0>},
> {name,query_servers},
> {mfa,{couch_query_servers,start_link,[]}},
> {restart_type,permanent},
> {shutdown,brutal_kill},
> {child_type,worker}]}]}}
> [Sun, 06 Dec 2009 22:10:15 GMT] [error] [<0.64.0>] Uncaught error in HTTP request:
{exit,
> {normal,
> {gen_server,call,
> [couch_query_servers,
> {ret_proc,
> {proc,<0.79.0>,<<"javascript">>,
> {couch_os_process,prompt},
> {couch_os_process,set_timeout},
> {couch_os_process,stop}}}]}}}
> [Sun, 06 Dec 2009 22:10:15 GMT] [info] [<0.64.0>] Stacktrace: [{gen_server,call,2},
> {couch_query_servers,ret_os_process,1},
> {couch_query_servers,render_doc_show,6},
> {couch_httpd_show,'-send_doc_show_response/6-fun-0-',6},
> {couch_httpd_db,do_db_req,2},
> {couch_httpd,handle_request,5},
> {mochiweb_http,headers,5},
> {proc_lib,init_p_do_apply,3}]
> [Sun, 06 Dec 2009 22:10:15 GMT] [info] [<0.64.0>] 127.0.0.1 - - 'GET' /r/_design/rofroks/_show/index
500
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Show returning zero length string results in scary errors
---------------------------------------------------------
Key: COUCHDB-593
URL: https://issues.apache.org/jira/browse/COUCHDB-593
Project: CouchDB
Issue Type: Bug
Components: JavaScript View Server
Affects Versions: 0.10
Environment: Ubuntu 9.10
Reporter: Roger Binns
If your show function returns a zero length string then several scary things happen. Arguably
the empty length string should just be returned to the browser.
function (doc,req) { return "";}
On returning the zero length string, the following is displayed in the browser:
{ret_proc,{proc,<0.79.0>,<<\"javascript\">>,\n
{couch_os_process,prompt},\n {couch_os_process,set_timeout},\n
{couch_os_process,stop}}}]}"}
The following is in the CouchDB log:
[Sun, 06 Dec 2009 22:10:15 GMT] [error] [<0.64.0>] OS Process Error :: {render_error,<<"undefined
response from show function">>}
[Sun, 06 Dec 2009 22:10:15 GMT] [error] [<0.53.0>] {error_report,<0.24.0>,
{<0.53.0>,supervisor_report,
[{supervisor,{local,couch_secondary_services}},
{errorContext,child_terminated},
{reason,normal},
{offender,[{pid,<0.58.0>},
{name,query_servers},
{mfa,{couch_query_servers,start_link,[]}},
{restart_type,permanent},
{shutdown,brutal_kill},
{child_type,worker}]}]}}
[Sun, 06 Dec 2009 22:10:15 GMT] [error] [<0.64.0>] Uncaught error in HTTP request: {exit,
{normal,
{gen_server,call,
[couch_query_servers,
{ret_proc,
{proc,<0.79.0>,<<"javascript">>,
{couch_os_process,prompt},
{couch_os_process,set_timeout},
{couch_os_process,stop}}}]}}}
[Sun, 06 Dec 2009 22:10:15 GMT] [info] [<0.64.0>] Stacktrace: [{gen_server,call,2},
{couch_query_servers,ret_os_process,1},
{couch_query_servers,render_doc_show,6},
{couch_httpd_show,'-send_doc_show_response/6-fun-0-',6},
{couch_httpd_db,do_db_req,2},
{couch_httpd,handle_request,5},
{mochiweb_http,headers,5},
{proc_lib,init_p_do_apply,3}]
[Sun, 06 Dec 2009 22:10:15 GMT] [info] [<0.64.0>] 127.0.0.1 - - 'GET' /r/_design/rofroks/_show/index
500
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
I have what I guess is a design question about Futon: I've been playing and prototyping with FTI in couchdb [1,2] and have tweaked Futon to replace the "Jump to ID" feature with "Search For:" [3] and an interesting question comes up. Currently I"m indexing all the values in the docs and returning the slot names as well as the doc ids in the search results. Even though couchdb is schema-less, there is an implicit schema within a given database as a rule. This is what allows us to define a Document object in Lucene which contains the fields we want to index up front. In this approach I'm indexing everything but of course in practice I may only be interested in particular slots like "PreferredName" or "GeneEncodes". So the question I have is how to control that in the search field, because it is database dependent. Should I let the display slot in jquery.suggest be configurable? I suppose one approach would be to index views rather that the entire document. This would be closer to how Lucene indexing works where the view itself defines the fields of interest. Still there may be multiple fields, so the question of how to configure the display remains. Anyway if this makes sense to anyone I'd appreciate your thoughts. Cheers, Bob [1] http://github.com/bdionne/indexer [2] http://github.com/bdionne/couchdb/tree/lucille [3] http://dionne.posterous.com/searching-in-futon-0
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Chris Anderson wrote: >> I'm inclined to agree with you. I'm working on a patch to make it so >> the show and list funs have access to the entire design document. This >> should facilitate what you are asking for. Would that also have the side effect of not needing the !code macros any more since you could just grab other functions directly out of the design doc? I had been considering plugging the Google Closure Javascript optimizer/recompiler into my couchapp equivalent. Of particular interest is its ability to remove unused code which is typical when using libraries. http://code.google.com/closure/compiler/ Also would the design document access be read-only or read-write? Roger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksbX0EACgkQmOOfHg372QQiAgCeMsH2vDffZ0gvN+g8Gru/QkvW LnAAoJeOuDuSLV37ysZO/8Ac688ffEYY =Q/Os -----END PGP SIGNATURE-----
On Sat, Dec 5, 2009 at 10:50 PM, Roger Binns <rogerb@rogerbinns.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Benoit Chesneau wrote: >> Well rewrite need to be fast. I don't like the idea of loading another >> doc. However since ddoc is already loaded it could be used in. We >> just spoke with jchris about such possibily. I think that it will do >> the trick. > > That is certainly better in my opinion than no doc at all. > >> You don't need to regerenate code you can use couchapp macro or any >> templating system in current solution. > > You are thinking as though you maintain couchapp :-) Sure that is no > problem for the developer of a CouchApp but consider what happens once you > deploy it. For example lets say there is a blogging CouchApp that people(*) > use and it has a debugging mode implemented by a rewrite (eg it rewrites > shows/lists with -debug suffix). It is far easier to change a single key on > the design doc (or whatever doc is presented to the _rewrite function) than > to require that user to download and install couchapp, edit the correct > files and redeploy. > > (*) As CouchDB becomes more successful the administrators and users of > CouchApps will increasingly have no knowledge of Javascript, what REST is, > how all the pieces fit together etc. Consider trying to explain how to > change a rewrite function versus telling them to go to futon and change a > key in the appropriate doc. I'm inclined to agree with you. I'm working on a patch to make it so the show and list funs have access to the entire design document. This should facilitate what you are asking for. Chris > > Roger > -----BEGIN PGP SIGNATURE----- > Version: GnuPG v1.4.9 (GNU/Linux) > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org > > iEYEARECAAYFAksbVBwACgkQmOOfHg372QS2uACgpeEMnCcp0ofbZxqSGg7UOeKZ > /zIAnRZNz3BJuE1G7SQlR4cOKzwfCIcy > =7lFb > -----END PGP SIGNATURE----- > > -- Chris Anderson http://jchrisa.net http://couch.io
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Benoit Chesneau wrote: > Well rewrite need to be fast. I don't like the idea of loading another > doc. However since ddoc is already loaded it could be used in. We > just spoke with jchris about such possibily. I think that it will do > the trick. That is certainly better in my opinion than no doc at all. > You don't need to regerenate code you can use couchapp macro or any > templating system in current solution. You are thinking as though you maintain couchapp :-) Sure that is no problem for the developer of a CouchApp but consider what happens once you deploy it. For example lets say there is a blogging CouchApp that people(*) use and it has a debugging mode implemented by a rewrite (eg it rewrites shows/lists with -debug suffix). It is far easier to change a single key on the design doc (or whatever doc is presented to the _rewrite function) than to require that user to download and install couchapp, edit the correct files and redeploy. (*) As CouchDB becomes more successful the administrators and users of CouchApps will increasingly have no knowledge of Javascript, what REST is, how all the pieces fit together etc. Consider trying to explain how to change a rewrite function versus telling them to go to futon and change a key in the appropriate doc. Roger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksbVBwACgkQmOOfHg372QS2uACgpeEMnCcp0ofbZxqSGg7UOeKZ /zIAnRZNz3BJuE1G7SQlR4cOKzwfCIcy =7lFb -----END PGP SIGNATURE-----
On Sun, Dec 6, 2009 at 12:27 AM, Roger Binns <rogerb@rogerbinns.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Benoit Chesneau wrote:
>> ? there is no prescribed behaviour
>
> With your current proposal behaviour is entirely determined by a Javascript
> function. What I am proposing is that Javascript function also be given a
> doc as input to do with as it pleases. There is no requirement for the doc
> to exist or the Javascript to pay any attention to it.
Well rewrite need to be fast. I don't like the idea of loading another
doc. However since ddoc is already loaded it could be used in. We
just spoke with jchris about such possibily. I think that it will do
the trick.
>
>> main point of _rewrite handler is to rewrite urls in a couchdb node or
>> even cluster not on different subnets.
>
> You missed my point. As an example a rewrite to a different show on the
> same server:
>
> function (req) {
> if (req.path ... matches ... "show/details")
> {
> if( isinternal(req) )
> return "... show/details-internal";
> return ".... show/details-public";
> }
> }
>
> Now the isinternal function needs to look at the IP address and would
> typically have a table of internal addresses. With the current scheme that
> table would have to be built into the Javascript.
I don't see to have it in js is a problem. For the function needed to
test the ip I think we could need to add the ip in headers of request
object.
However I would stronly recommend to not rely on such function if you
need security. It's better to use a proxy and pass right auth headers.
>
>> system to rewrite urls. Sometimes you want to rewrite depending on
>> http verb, other depending on auth or simply on path and there are
>> different need for rewriting on patch too. The current design allow
>> you to define your own way to do this. You could always make a
>> template that allows you to create your own set of rules.
>
> With your current proposal, code has to look like this:
>
> function (req) {
> var data={ ... a bunch of data ... };
>
> if/return/etc looking at the req and data
> }
>
> What I am asking for is the ability to have it like this:
>
> function (req, doc) {
> if/return/etc looking at the req and data in doc
> }
>
> With your current proposal, changing the data used by the function requires
> regenerating Javascript code. If the data can (optionally) live in a
> document then no code generation is required nor is rewriting the design doc.
>
> I would expect developers to come up with some useful rewriters. For
> example maybe one that switches between production and development mode. Or
> maybe some sort of aliasing as you suggested. It would be nice to be able
> to control their behaviour by editing the contents of a regular doc rather
> than having to edit Javascript code and regenerating design docs.
>
You don't need to regerenate code you can use couchapp macro or any
templating system in current solution. However if you have access to
ddoc in function, you won't have to do this even.
- benoît
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Benoit Chesneau wrote:
> ? there is no prescribed behaviour
With your current proposal behaviour is entirely determined by a Javascript
function. What I am proposing is that Javascript function also be given a
doc as input to do with as it pleases. There is no requirement for the doc
to exist or the Javascript to pay any attention to it.
> main point of _rewrite handler is to rewrite urls in a couchdb node or
> even cluster not on different subnets.
You missed my point. As an example a rewrite to a different show on the
same server:
function (req) {
if (req.path ... matches ... "show/details")
{
if( isinternal(req) )
return "... show/details-internal";
return ".... show/details-public";
}
}
Now the isinternal function needs to look at the IP address and would
typically have a table of internal addresses. With the current scheme that
table would have to be built into the Javascript.
> system to rewrite urls. Sometimes you want to rewrite depending on
> http verb, other depending on auth or simply on path and there are
> different need for rewriting on patch too. The current design allow
> you to define your own way to do this. You could always make a
> template that allows you to create your own set of rules.
With your current proposal, code has to look like this:
function (req) {
var data={ ... a bunch of data ... };
if/return/etc looking at the req and data
}
What I am asking for is the ability to have it like this:
function (req, doc) {
if/return/etc looking at the req and data in doc
}
With your current proposal, changing the data used by the function requires
regenerating Javascript code. If the data can (optionally) live in a
document then no code generation is required nor is rewriting the design doc.
I would expect developers to come up with some useful rewriters. For
example maybe one that switches between production and development mode. Or
maybe some sort of aliasing as you suggested. It would be nice to be able
to control their behaviour by editing the contents of a regular doc rather
than having to edit Javascript code and regenerating design docs.
Roger
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAksa7EwACgkQmOOfHg372QRcxQCggrhGm8SYYAtGcvAyjE9YHhO1
1kcAoISIPlwFw85odHKooYcaiXsUzDut
=EvTt
-----END PGP SIGNATURE-----
On Sat, Dec 5, 2009 at 8:15 PM, Roger Binns <rogerb@rogerbinns.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Benoit Chesneau wrote: >> what would do this doc? > > Nothing in particular - it would just be provided to the _rewrite handler > Javascript code to do with as it pleases with no prescribed behaviour. ? there is no prescribed behaviour > > The ways I would use it if it existed: > > - - Rewrite to different URIs depending on if the request comes from an > internal or external location. The doc would have a list of subnets > considered internal. main point of _rewrite handler is to rewrite urls in a couchdb node or even cluster not on different subnets. Proxies are better for that. > > - - If my app had 10 components, I'd store in the doc which ones are active > and which disabled (eg disabled ones could be redirected to a page > explaining that). not sure to understand here why it couldn't works. make your rules per component. If you want ro be restful anyway, rules are per resources > > - - I'd prefer to have my rules listed as data with my Javascript code > applying them. With the current approach a Javascript has to be regenerated > on any rule change. > urls don't change often. Current system allows you to define your own system to rewrite urls. Sometimes you want to rewrite depending on http verb, other depending on auth or simply on path and there are different need for rewriting on patch too. The current design allow you to define your own way to do this. You could always make a template that allows you to create your own set of rules. One other handler I have in mind is an alias handler who could keep results based on a view so you could eventually associate alias to docid and useit as url. Useful for shows for example. But that's just an idea for now. - benoît
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Benoit Chesneau wrote: > what would do this doc? Nothing in particular - it would just be provided to the _rewrite handler Javascript code to do with as it pleases with no prescribed behaviour. The ways I would use it if it existed: - - Rewrite to different URIs depending on if the request comes from an internal or external location. The doc would have a list of subnets considered internal. - - If my app had 10 components, I'd store in the doc which ones are active and which disabled (eg disabled ones could be redirected to a page explaining that). - - I'd prefer to have my rules listed as data with my Javascript code applying them. With the current approach a Javascript has to be regenerated on any rule change. Roger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksasTMACgkQmOOfHg372QQi/gCfZkuPASwI4562apjU7CMOcBs5 dMUAoK4Nmy8rVJcP8AK+s7A2Ma1nyJBc =Tjfo -----END PGP SIGNATURE-----
On Sat, Dec 5, 2009 at 7:14 AM, Jan Lehnardt <jan@apache.org> wrote:
>
> On 24 Nov 2009, at 06:14, Paul Davis wrote:
>
>> Dev People,
>>
>> Its no secret that I've been trying to find a reason to delete all of
>> the temp_view logic in the view code. I was just discussing the
>> internal view API with Adam Kocoloski on IRC and it hit me that with
>> the index-filename-from-md5 patch that Chris Anderson landed a while
>> ago could make it all go away.
>>
>> The proposed API would be something like:
>>
>> couch_view:get_view(DesignDoc) -> #view{}
>>
>> Where DesignDoc is the ErlJSON representation of that design doc. Then
>> temp_views would just create the ErlJSON representation (without
>> saving that doc in the DB) and pass it to the view update mechanics.
>> Cleaning up old temp views would then just use the existing cleanup
>> mechanism we already have in place.
>>
>> AFAICT, this doesn't introduce any sort of oddities that don't already
>> exist and provides better semantics for promoting a temp_view to a
>> permanent view because the index wouldn't need to be rebuilt.
>>
>> Then again I'm a bit tired so I could be off my rocker. Anyone see
>> anything obviously wrong?
>
> The only thing I'd advocate is that we make it more apparent in Futon
> that view cleanup is needed. Otherwise, I like the idea of removing that
> code.
>
So the idea is that this wouldn't change the HTTP API, just how it's
implemented? If so, then by all means yes.
If you are going to work on this, I think it should be done on top of
my design doc handlers patch [1], as I'm already moving the loading of
the design doc to the front of the request handling. The changes
you'll have to make to make this happen will play right into the rest
of that patch.
I'm glad we found a synergy here - I knew the patch would make things
simpler but I didn't realize it would help with this too.
Chris
[1] http://issues.apache.org/jira/browse/COUCHDB-589 (I have done more
work in git, I'll make that available asap)
--
Chris Anderson
http://jchrisa.net
http://couch.io
On 24 Nov 2009, at 06:14, Paul Davis wrote:
> Dev People,
>
> Its no secret that I've been trying to find a reason to delete all of
> the temp_view logic in the view code. I was just discussing the
> internal view API with Adam Kocoloski on IRC and it hit me that with
> the index-filename-from-md5 patch that Chris Anderson landed a while
> ago could make it all go away.
>
> The proposed API would be something like:
>
> couch_view:get_view(DesignDoc) -> #view{}
>
> Where DesignDoc is the ErlJSON representation of that design doc. Then
> temp_views would just create the ErlJSON representation (without
> saving that doc in the DB) and pass it to the view update mechanics.
> Cleaning up old temp views would then just use the existing cleanup
> mechanism we already have in place.
>
> AFAICT, this doesn't introduce any sort of oddities that don't already
> exist and provides better semantics for promoting a temp_view to a
> permanent view because the index wouldn't need to be rebuilt.
>
> Then again I'm a bit tired so I could be off my rocker. Anyone see
> anything obviously wrong?
The only thing I'd advocate is that we make it more apparent in Futon
that view cleanup is needed. Otherwise, I like the idea of removing that
code.
Cheers
Jan
--
On Saturday, December 5, 2009, Roger Binns <rogerb@rogerbinns.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > Benoit Chesneau wrote: >> The design is very simple. Everything is managed via a simple >> javascript function that return a path or throw 'forbidden', >> 'unauthorized' and "not found" errors. The request object is passed to >> the function and then depending on the path, verb or userCtx you could >> decide how to rewrite the path. > > Is there any chance it could a document too? For example it would be really > nice if there was a document with an _id of "_rewrite_config" (or something > similar) that was also passed to the function. That document can then help > parameterize what the rewriter does. > > Roger what would do this doc?
[ https://issues.apache.org/jira/browse/COUCHDB-592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12786312#action_12786312
]
Noah Slater commented on COUCHDB-592:
-------------------------------------
I am happy to review and apply a patch that adds this as an option to configure, as long as
the actual build is taken care of properly.
> Build and configure without the js library
> ------------------------------------------
>
> Key: COUCHDB-592
> URL: https://issues.apache.org/jira/browse/COUCHDB-592
> Project: CouchDB
> Issue Type: New Feature
> Components: Build System
> Environment: Any?
> Reporter: Ari Lerner
>
> I am trying to use couchdb without the requirements of the js library. I will not be
accessing couch (nor do I want access) through an http interface, but an erlang client library.
> Thanks
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Benoit Chesneau wrote: > The design is very simple. Everything is managed via a simple > javascript function that return a path or throw 'forbidden', > 'unauthorized' and "not found" errors. The request object is passed to > the function and then depending on the path, verb or userCtx you could > decide how to rewrite the path. Is there any chance it could a document too? For example it would be really nice if there was a document with an _id of "_rewrite_config" (or something similar) that was also passed to the function. That document can then help parameterize what the rewriter does. Roger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksZvu0ACgkQmOOfHg372QRHXQCdFT2mpbYNpocVrs4vwhjL1xgc 2mAAoLMfzx3zOlEyasKK3hsc/cnqkvHv =Qj3u -----END PGP SIGNATURE-----
This thing was long awaited!
Thank you for the effort, Benoît!
On Fri, Dec 4, 2009 at 6:30 PM, Benoit Chesneau <bchesneau@gmail.com> wrote:
> Hi all,
>
> I created a branch* Â based on trunk on my Github repository that
> allows url rewriting in CouchDB:
>
> http://github.com/benoitc/couchdb/tree/rewrite
>
> The design is very simple. Everything is managed via a simple
> javascript function that return a path or throw 'forbidden',
> 'unauthorized' and "not found" errors. The request object is passed to
> the function and then depending on the path, verb or userCtx you could
> decide how to rewrite the path. All relatives path are relative to
> design doc.
>
> Â The _rewriter is available at db or _design level :
>
> /db/_rewrite/designname/path
>
> or
>
> /db/_design/designame/_rewrite/path.
>
>
> Then _rewrite handler look in design doc if `rewrite` member exists
> and load the function.
>
> Little snippets from tests :
>
> function(req) {
> Â Â path = "/" + req.path.join('/');
>
> Â Â if (path == "/forbidden") {
> Â Â Â Â throw {
> Â Â Â Â Â Â forbidden:
> Â Â Â Â Â Â "path forbidden"
> Â Â Â Â };
> Â Â }
> Â Â if (path == "/unauthorized") {
> Â Â Â Â throw {
> Â Â Â Â Â Â unauthorized:
> Â Â Â Â Â Â "path not authorized"
> Â Â Â Â };
> Â Â }
> Â Â if (path == "/notfound") {
> Â Â Â Â throw {
> Â Â Â Â Â Â not_found:
> Â Â Â Â Â Â "path not found"
> Â Â Â Â };
> Â Â }
>
> Â Â if (path == "/foo") {
> Â Â Â Â return "foo.txt"
> Â Â }
>
> Â Â var matches = path.match(/^\/hello\/(\w.+)$/);
>
> Â Â if (matches[1]) {
> Â Â Â Â if (req.verb == "DELETE") {
> Â Â Â Â Â Â throw {
> Â Â Â Â Â Â Â Â forbidden:
> Â Â Â Â Â Â Â Â "delete is forbidden"
> Â Â Â Â Â Â };
> Â Â Â Â }
> Â Â Â Â return "_update/hello/" + matches[1];
> Â Â }
> }
>
>
> let me know if it's ok for you,
>
> - benoît
>
Gut! =) On Thu, Dec 3, 2009 at 9:21 PM, Noah Slater <nslater@tumbolia.org> wrote: > Hello, > > Apache CouchDB 0.10.1 has been released and is available for download: > >     http://couchdb.apache.org/downloads.html > > Changes in this release: > >     * Fixed test suite to work with build system. >     * Fixed a problem with statistics timers and system sleep. >     * Fixed an edge case for HTTP redirects during replication. >     * Fixed HTTP timeout handling for replication. >     * Fixed query parameter handling in OAuth’d replication. >     * Fixed a bug preventing mixing languages with lists and views. >     * Avoid OS process leaks in lists. > > CouchDB is a document-oriented database that can be queried and indexed in a MapReduce fashion using JavaScript. CouchDB also offers incremental replication with bi-directional conflict detection and resolution. > > CouchDB provides a RESTful JSON API than can be accessed from any environment that allows HTTP requests. There are myriad third-party client libraries that make this even easier from your programming language of choice. CouchDB's built in Web administration console speaks directly to the database using HTTP requests issued from your browser. > > CouchDB is written in Erlang, a robust functional programming language ideal for building concurrent distributed systems. Erlang allows for a flexible design that is easily scalable and readily extensible. > > Relax and prosper, > > Noah
[ https://issues.apache.org/jira/browse/COUCHDB-592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12786243#action_12786243
]
Paul Joseph Davis commented on COUCHDB-592:
-------------------------------------------
The downside is on the theoretical side and for me its a hold the line type of position. I
wouldn't veto a patch for it but I'm not about to write it.
The issue is that once we start doing allowing the official releases to have all sorts of
conditional compilation options we have to officially support each permutation of those options.
Spending extra time tracking down weird compilation configurations is not something I would
enjoy.
And there's also the fact that this is a pretty easy hack to remove all parts of the build
system that'd require JS, cURL, and ICU. And the build system doesn't change *that* often
so it wouldn't be hard too hard to keep in sync outside of trunk.
> Build and configure without the js library
> ------------------------------------------
>
> Key: COUCHDB-592
> URL: https://issues.apache.org/jira/browse/COUCHDB-592
> Project: CouchDB
> Issue Type: New Feature
> Components: Build System
> Environment: Any?
> Reporter: Ari Lerner
>
> I am trying to use couchdb without the requirements of the js library. I will not be
accessing couch (nor do I want access) through an http interface, but an erlang client library.
> Thanks
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/COUCHDB-592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12786159#action_12786159
]
Ari Lerner commented on COUCHDB-592:
------------------------------------
Perhaps I'm mistaken, but I don't see the downsides to providing a --without-js-libs option
to the configure script...
> Build and configure without the js library
> ------------------------------------------
>
> Key: COUCHDB-592
> URL: https://issues.apache.org/jira/browse/COUCHDB-592
> Project: CouchDB
> Issue Type: New Feature
> Components: Build System
> Environment: Any?
> Reporter: Ari Lerner
>
> I am trying to use couchdb without the requirements of the js library. I will not be
accessing couch (nor do I want access) through an http interface, but an erlang client library.
> Thanks
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/COUCHDB-592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12786157#action_12786157
]
Paul Joseph Davis commented on COUCHDB-592:
-------------------------------------------
Also, I should mention that I don't really foresee providing this as part of any official
distribution. Its pretty core to CouchDB to provide these things, and removing them should
be considered a private modification. It really shouldn't be too hard though.
> Build and configure without the js library
> ------------------------------------------
>
> Key: COUCHDB-592
> URL: https://issues.apache.org/jira/browse/COUCHDB-592
> Project: CouchDB
> Issue Type: New Feature
> Components: Build System
> Environment: Any?
> Reporter: Ari Lerner
>
> I am trying to use couchdb without the requirements of the js library. I will not be
accessing couch (nor do I want access) through an http interface, but an erlang client library.
> Thanks
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/COUCHDB-592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12786156#action_12786156
]
Paul Joseph Davis commented on COUCHDB-592:
-------------------------------------------
Don't forget the ICU dependency that you'd have to remove as well then.
> Build and configure without the js library
> ------------------------------------------
>
> Key: COUCHDB-592
> URL: https://issues.apache.org/jira/browse/COUCHDB-592
> Project: CouchDB
> Issue Type: New Feature
> Components: Build System
> Environment: Any?
> Reporter: Ari Lerner
>
> I am trying to use couchdb without the requirements of the js library. I will not be
accessing couch (nor do I want access) through an http interface, but an erlang client library.
> Thanks
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/COUCHDB-592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12786155#action_12786155
]
Ari Lerner commented on COUCHDB-592:
------------------------------------
That's exactly what I want Glenn.
The extra dependency of the JS library is limiting and somewhat of a deal-breaker for the
project I'm working on (in an environment where every dependency is a hurdle for implementation)
> Build and configure without the js library
> ------------------------------------------
>
> Key: COUCHDB-592
> URL: https://issues.apache.org/jira/browse/COUCHDB-592
> Project: CouchDB
> Issue Type: New Feature
> Components: Build System
> Environment: Any?
> Reporter: Ari Lerner
>
> I am trying to use couchdb without the requirements of the js library. I will not be
accessing couch (nor do I want access) through an http interface, but an erlang client library.
> Thanks
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/COUCHDB-592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12786150#action_12786150
]
Glenn Rempe commented on COUCHDB-592:
-------------------------------------
Noah,
I believe you can use CouchDB without http access if you use the Hovercraft Erlang library.
http://github.com/jchris/hovercraft
http://github.com/grempe/hovercraft (Includes fixes for trunk couchdb pending merge to jchris
master)
If you mixed that with Erlang views wouldn't that be a reason to want to eliminate any external
build time dependencies other than Erlang? CouchDB should optimally be able to operate in
pure erlang mode. No? This is something the couchdb team should encourage imho.
> Build and configure without the js library
> ------------------------------------------
>
> Key: COUCHDB-592
> URL: https://issues.apache.org/jira/browse/COUCHDB-592
> Project: CouchDB
> Issue Type: New Feature
> Components: Build System
> Environment: Any?
> Reporter: Ari Lerner
>
> I am trying to use couchdb without the requirements of the js library. I will not be
accessing couch (nor do I want access) through an http interface, but an erlang client library.
> Thanks
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/COUCHDB-592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12786121#action_12786121
]
Paul Joseph Davis commented on COUCHDB-592:
-------------------------------------------
The quickest thing to do would be to delete the relevant sections from configure.ac and src/couchdb/priv/Makefile
to avoid that. Though be aware that at some time in the nearish future JS might be a test
time dependency so you won't be able to run the test suite from make check.
> Build and configure without the js library
> ------------------------------------------
>
> Key: COUCHDB-592
> URL: https://issues.apache.org/jira/browse/COUCHDB-592
> Project: CouchDB
> Issue Type: New Feature
> Components: Build System
> Environment: Any?
> Reporter: Ari Lerner
>
> I am trying to use couchdb without the requirements of the js library. I will not be
accessing couch (nor do I want access) through an http interface, but an erlang client library.
> Thanks
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/COUCHDB-592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12786088#action_12786088
]
Ari Lerner commented on COUCHDB-592:
------------------------------------
I don't want to have to require the SpiderMonkey javascript library when building couch.
> Build and configure without the js library
> ------------------------------------------
>
> Key: COUCHDB-592
> URL: https://issues.apache.org/jira/browse/COUCHDB-592
> Project: CouchDB
> Issue Type: New Feature
> Components: Build System
> Environment: Any?
> Reporter: Ari Lerner
>
> I am trying to use couchdb without the requirements of the js library. I will not be
accessing couch (nor do I want access) through an http interface, but an erlang client library.
> Thanks
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[ https://issues.apache.org/jira/browse/COUCHDB-592?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12786082#action_12786082
]
Noah Slater commented on COUCHDB-592:
-------------------------------------
I'm not sure what you want.
Do you want to be able to disable the building of any JS component at all? Why?
What has that to do with HTTP? There is no way to use CouchDB without using HTTP at the emoment.
> Build and configure without the js library
> ------------------------------------------
>
> Key: COUCHDB-592
> URL: https://issues.apache.org/jira/browse/COUCHDB-592
> Project: CouchDB
> Issue Type: New Feature
> Components: Build System
> Environment: Any?
> Reporter: Ari Lerner
>
> I am trying to use couchdb without the requirements of the js library. I will not be
accessing couch (nor do I want access) through an http interface, but an erlang client library.
> Thanks
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
interesting. I just tried this in Distel and am able to step through it just fine. I would
think at some level Distel is using the Erlang debugger.
On Dec 4, 2009, at 1:48 PM, Filipe David Manana wrote:
> Hello,
> thanks for the suggestion Torbjörn, I had not yet the time to test it
> but it seems promising (I am mostly an Emacs user also). It's on my
> todo list now.
>
> I found the cause of the problem. When debugging using Erlang's
> debugger, he considers the Length variable used in the second case
> statement (attribution to #att.len) to be already bound. This is so
> because the previous case statement also uses a variable named Length
> in 2 of its branches.
>
> Just renaming the second one from Length to Length2
> (chouch_httpd_db.erl line 1045) avoids the badmatch error:
>
> [#att{
> name = FileName,
> type = case couch_httpd:header_value(Req,"Content-Type") of
> undefined ->
> % We could throw an error here or guess by the FileName.
> % Currently, just giving it a default.
> <<"application/octet-stream">>;
> CType ->
> list_to_binary(CType)
> end,
> data = case couch_httpd:body_length(Req) of
> undefined ->
> <<"">>;
> {unknown_transfer_encoding, Unknown} ->
> exit({unknown_transfer_encoding, Unknown});
> chunked ->
> fun(MaxChunkSize, ChunkFun, InitState) ->
> couch_httpd:recv_chunked(Req, MaxChunkSize,
> ChunkFun, InitState)
> end;
> 0 ->
> <<"">>;
> Length when is_integer(Length) ->
> fun() -> couch_httpd:recv(Req, 0) end;
> Length ->
> exit({length_not_integer, Length})
> end,
> len = case couch_httpd:header_value(Req,"Content-Length") of
> undefined ->
> undefined;
> Length2 ->
> list_to_integer(Length2)
> end
> }]
> end,
>
> I wonder why this badmatch error only occurs when interpreting the
> code with the debugger and not during normal execution.
> Anyone has a clue?
>
> cheers
>
> 2009/12/2 Torbjörn Törnkvist <tobbe@klarna.com>:
>> For some more light weight debugging I can recomend redbug. It is included
>> in the eper repo at google code.
>>
>> --Tobbe
>>
>> Den 12 1, 2009 11:50 PM, "Robert Dionne" <dionne@dionne-associates.com>
>> skrev:
>>
>> I've had great luck using Distel[1] on top of aquamacs. Bill Clementson
>> wrote a couple of nice how to pieces[2] to get you started. Works like a
>> champ
>>
>> [1] http://github.com/bdionne/distel
>> [2] http://bc.tech.coop/blog/070528.html
>>
>> On Dec 1, 2009, at 5:34 PM, Filipe David Manana wrote: > Hello, > > I am
>> having a strange sit...
>>
>
>
>
> --
> Filipe David Manana,
> fdmanana@gmail.com
> PGP key - http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC569452B
>
> "Reasonable men adapt themselves to the world.
> Unreasonable men adapt the world to themselves.
> That's why all progress depends on unreasonable men."
Hello,
thanks for the suggestion Torbjörn, I had not yet the time to test it
but it seems promising (I am mostly an Emacs user also). It's on my
todo list now.
I found the cause of the problem. When debugging using Erlang's
debugger, he considers the Length variable used in the second case
statement (attribution to #att.len) to be already bound. This is so
because the previous case statement also uses a variable named Length
in 2 of its branches.
Just renaming the second one from Length to Length2
(chouch_httpd_db.erl line 1045) avoids the badmatch error:
[#att{
name = FileName,
type = case couch_httpd:header_value(Req,"Content-Type") of
undefined ->
% We could throw an error here or guess by the FileName.
% Currently, just giving it a default.
<<"application/octet-stream">>;
CType ->
list_to_binary(CType)
end,
data = case couch_httpd:body_length(Req) of
undefined ->
<<"">>;
{unknown_transfer_encoding, Unknown} ->
exit({unknown_transfer_encoding, Unknown});
chunked ->
fun(MaxChunkSize, ChunkFun, InitState) ->
couch_httpd:recv_chunked(Req, MaxChunkSize,
ChunkFun, InitState)
end;
0 ->
<<"">>;
Length when is_integer(Length) ->
fun() -> couch_httpd:recv(Req, 0) end;
Length ->
exit({length_not_integer, Length})
end,
len = case couch_httpd:header_value(Req,"Content-Length") of
undefined ->
undefined;
Length2 ->
list_to_integer(Length2)
end
}]
end,
I wonder why this badmatch error only occurs when interpreting the
code with the debugger and not during normal execution.
Anyone has a clue?
cheers
2009/12/2 Torbjörn Törnkvist <tobbe@klarna.com>:
> For some more light weight debugging I can recomend redbug. Â It is included
> in the eper repo at google code.
>
> --Tobbe
>
> Den 12 1, 2009 11:50 PM, "Robert Dionne" <dionne@dionne-associates.com>
> skrev:
>
> I've had great luck using Distel[1] Â on top of aquamacs. Bill Clementson
> wrote a couple of nice how to pieces[2] to get you started. Works like a
> champ
>
> [1] http://github.com/bdionne/distel
> [2] http://bc.tech.coop/blog/070528.html
>
> On Dec 1, 2009, at 5:34 PM, Filipe David Manana wrote: > Hello, > > I am
> having a strange sit...
>
--
Filipe David Manana,
fdmanana@gmail.com
PGP key - http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xC569452B
"Reasonable men adapt themselves to the world.
Unreasonable men adapt the world to themselves.
That's why all progress depends on unreasonable men."
Build and configure without the js library
------------------------------------------
Key: COUCHDB-592
URL: https://issues.apache.org/jira/browse/COUCHDB-592
Project: CouchDB
Issue Type: New Feature
Components: Build System
Environment: Any?
Reporter: Ari Lerner
I am trying to use couchdb without the requirements of the js library. I will not be accessing
couch (nor do I want access) through an http interface, but an erlang client library.
Thanks
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Support for compressed attachments? I think there's a ticket for it, but the basic idea is to support Accept-Encoding/Content-Encoding form the client and store the attachment with compression (and decompressing on demand). A bulk insertion endpoint that included attachments (without base64 inflation) would also be nice. On Fri, Dec 4, 2009 at 5:55 PM, Dirkjan Ochtman <djc.ochtman@gmail.com> wrote: > On Fri, Dec 4, 2009 at 18:32, Noah Slater <nslater@tumbolia.org> wrote: >> Hey, does anyone want to start the discussion off? > > Question from one of those trailing around on actual releases, that > may help getting started: what big-ticket features are in trunk, but > not 0.10.1? > > Cheers, > > Dirkjan >
On Fri, Dec 4, 2009 at 18:32, Noah Slater <nslater@tumbolia.org> wrote: > Hey, does anyone want to start the discussion off? Question from one of those trailing around on actual releases, that may help getting started: what big-ticket features are in trunk, but not 0.10.1? Cheers, Dirkjan
On 3 Dec 2009, at 19:29, Noah Slater wrote: > As part of the release procedure, this is a request to update the roadmap document: > > http://couchdb.apache.org/roadmap.html > > Please comment on what should be added, and what should be removed. > > After a we reach consensus, I will update the roadmap. Hey, does anyone want to start the discussion off?