[jira] [Assigned] (COUCHDB-1012) Utility to help plugin developers manage paths
[ https://issues.apache.org/jira/browse/COUCHDB-1012?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Randall Leeds reassigned COUCHDB-1012: -- Assignee: Randall Leeds (was: Noah Slater) Assigning back to me since I'm almost done cleaning this up. > Utility to help plugin developers manage paths > -- > > Key: COUCHDB-1012 > URL: https://issues.apache.org/jira/browse/COUCHDB-1012 > Project: CouchDB > Issue Type: New Feature > Components: Build System >Reporter: Randall Leeds >Assignee: Randall Leeds > Fix For: 1.2 > > Attachments: > 0001-add-couch-config-file-used-to-ease-the-build-of-plug.patch, > 0001-add-couch-config-file-used-to-ease-the-build-of-plug.patch, > 0001-support-pkg-config-for-plugins-COUCHDB-1012.patch > > > Developers may want to write plugins (like GeoCouch) for CouchDB. Many hooks > in the configuration system allow loading arbitrary Erlang modules to handle > various internal tasks, but currently there is no straightforward and > portable way for developers of these plugins to discover the location of the > CouchDB library files. > Two options that have been proposed are to use pkg-config or install a > separate script that could be invoked (e.g. as couch-config --erl-libs) to > discover important CouchDB installation paths. > As far as I know the loudest argument against pkg-config is lack of support > for Windows. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1012) Utility to help plugin developers manage paths
[ https://issues.apache.org/jira/browse/COUCHDB-1012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13088291#comment-13088291 ] Paul Joseph Davis commented on COUCHDB-1012: couch-config --couchconfdir vs couch-config --cfg-dir Am I the only one scratching their head why this is so complicated? > Utility to help plugin developers manage paths > -- > > Key: COUCHDB-1012 > URL: https://issues.apache.org/jira/browse/COUCHDB-1012 > Project: CouchDB > Issue Type: New Feature > Components: Build System >Reporter: Randall Leeds >Assignee: Noah Slater > Fix For: 1.2 > > Attachments: > 0001-add-couch-config-file-used-to-ease-the-build-of-plug.patch, > 0001-add-couch-config-file-used-to-ease-the-build-of-plug.patch, > 0001-support-pkg-config-for-plugins-COUCHDB-1012.patch > > > Developers may want to write plugins (like GeoCouch) for CouchDB. Many hooks > in the configuration system allow loading arbitrary Erlang modules to handle > various internal tasks, but currently there is no straightforward and > portable way for developers of these plugins to discover the location of the > CouchDB library files. > Two options that have been proposed are to use pkg-config or install a > separate script that could be invoked (e.g. as couch-config --erl-libs) to > discover important CouchDB installation paths. > As far as I know the loudest argument against pkg-config is lack of support > for Windows. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-605) _update handler doesn't conflict for existing document
[
https://issues.apache.org/jira/browse/COUCHDB-605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13088284#comment-13088284
]
Robert Newson commented on COUCHDB-605:
---
_update handlers do not allow you to ignore MVCC, the update can still fail
with a real 409 if the doc is updated concurrently. All it's doing is giving
you the current _rev value, but it's not performing any locking (there are no
read or write locks in couchdb) so a successful update between the start of the
update function and its return will cause the update handler to fail with 409.
> _update handler doesn't conflict for existing document
> --
>
> Key: COUCHDB-605
> URL: https://issues.apache.org/jira/browse/COUCHDB-605
> Project: CouchDB
> Issue Type: Bug
>Affects Versions: 0.10
> Environment: Ubuntu Karmic, in particular it's CouchDB version
> 0.10.0-0ubuntu3
>Reporter: Sergey Shepelev
>Assignee: Chris Anderson
>
> design doc:
> "updates": {
>"hello": "function(doc, req) { doc.value = 100500; return [doc, 'foo
> bar']; }"
>}
> $ curl -X PUT --data-binary @- http://localhost:5984/shkaf/client:foo << EOF
> > {"_id":"client:foo"}
> > EOF
> {"ok":true,"id":"client:foo","rev":"1-967a00dff5e02add41819138abb3284d"}
> $ curl -X PUT --data-binary @-
> http://localhost:5984/shkaf/_design/client/_update/hello/client:foo?A=B << EOF
> > {"_id": "client:foo"}
> > EOF
> foo bar
> And it really updated the document.
> What i expected here is error: conflict because document with such _id
> already existed and i didn't provide _rev to _update handler.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1012) Utility to help plugin developers manage paths
[ https://issues.apache.org/jira/browse/COUCHDB-1012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13088281#comment-13088281 ] Randall Leeds commented on COUCHDB-1012: I'm just going to trust Noah here, but I'd like to see CouchDB-specific options listed first and to see the reconfigurable options left out: localstate*dir. I think localdatadir needs to be there, but should be renamed to reflect what it is: static resources used by the HTTP server (futon, js tests, etc). Not sure what name that should be. How about this list: CouchDB variables: --couchconfdir configuration data [SYSCONFDIR/$package_identifier] --couchstaticroot runtime data [DATADIR/$package_identifier] ^^ please help me name this one --couchlibdir library data [LIBDIR/$package_identifier] ^^ this should be the /erlang/lib dir, either the system erlang (Windows and CentOS packages do this) or Couch's private one in LIBDIR/couchdb/erlang/lib Other variables: We don't install to most of these. It's strange to me that autoconf still generates a configure with all these options even when we don't use most of them. I'm fine with keeping any and all of them, as long as we list it after the CouchDB ones. --libexecdir program executables [EPREFIX/libexec] --sharedstatedir modifiable architecture-independent data [PREFIX/com] --infodir info documentation [DATAROOTDIR/info] --localedir locale-dependent data [DATAROOTDIR/locale] --docdir documentation root [DATAROOTDIR/doc/apache-couchdb] --htmldir html documentation [DOCDIR] --dvidir dvi documentation [DOCDIR] --pdfdir pdf documentation [DOCDIR] --psdir ps documentation [DOCDIR] Is this getting closer? > Utility to help plugin developers manage paths > -- > > Key: COUCHDB-1012 > URL: https://issues.apache.org/jira/browse/COUCHDB-1012 > Project: CouchDB > Issue Type: New Feature > Components: Build System >Reporter: Randall Leeds >Assignee: Noah Slater > Fix For: 1.2 > > Attachments: > 0001-add-couch-config-file-used-to-ease-the-build-of-plug.patch, > 0001-add-couch-config-file-used-to-ease-the-build-of-plug.patch, > 0001-support-pkg-config-for-plugins-COUCHDB-1012.patch > > > Developers may want to write plugins (like GeoCouch) for CouchDB. Many hooks > in the configuration system allow loading arbitrary Erlang modules to handle > various internal tasks, but currently there is no straightforward and > portable way for developers of these plugins to discover the location of the > CouchDB library files. > Two options that have been proposed are to use pkg-config or install a > separate script that could be invoked (e.g. as couch-config --erl-libs) to > discover important CouchDB installation paths. > As far as I know the loudest argument against pkg-config is lack of support > for Windows. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-985) Update handlers can make documents with blank _id
[
https://issues.apache.org/jira/browse/COUCHDB-985?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13088264#comment-13088264
]
Benjamin Young commented on COUCHDB-985:
This is still a problem in the latest trunk and it removes the ability to
DELETE the doc via /{db}/{doc} as {doc} can't == "" as you'd then delete the DB.
> Update handlers can make documents with blank _id
> -
>
> Key: COUCHDB-985
> URL: https://issues.apache.org/jira/browse/COUCHDB-985
> Project: CouchDB
> Issue Type: Bug
> Components: Database Core, JavaScript View Server
>Affects Versions: 1.0.1
> Environment: OS X, built using brew
>Reporter: Nick Fisher
>Priority: Minor
>
> Make the following update handler:
> '''
> function(doc, req){
> return [{}, 'done\n'];
> }
> '''
> Then do a POST to the handler. You will then have a document with a blank _id.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-605) _update handler doesn't conflict for existing document
[
https://issues.apache.org/jira/browse/COUCHDB-605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13088260#comment-13088260
]
Benjamin Young commented on COUCHDB-605:
I see this as part of the benefit/usefulness of _update--that you can, as
needed, ignore the MVCC pattern and update a doc regardless of matching _rev's.
However, it should be possible to implement this by comparing a "rev" query
param to the doc._rev if an existing ID is used. Sadly, (due to issue
COUCHDB-648) it's not possible to send 409 Conflict error "by hand" (or any
other developer chosen status code).
Basically, _update handlers seem to need a bit more love before they'll be
completely useful for stand-along apps or APIs built on top of CouchDB.
> _update handler doesn't conflict for existing document
> --
>
> Key: COUCHDB-605
> URL: https://issues.apache.org/jira/browse/COUCHDB-605
> Project: CouchDB
> Issue Type: Bug
>Affects Versions: 0.10
> Environment: Ubuntu Karmic, in particular it's CouchDB version
> 0.10.0-0ubuntu3
>Reporter: Sergey Shepelev
>Assignee: Chris Anderson
>
> design doc:
> "updates": {
>"hello": "function(doc, req) { doc.value = 100500; return [doc, 'foo
> bar']; }"
>}
> $ curl -X PUT --data-binary @- http://localhost:5984/shkaf/client:foo << EOF
> > {"_id":"client:foo"}
> > EOF
> {"ok":true,"id":"client:foo","rev":"1-967a00dff5e02add41819138abb3284d"}
> $ curl -X PUT --data-binary @-
> http://localhost:5984/shkaf/_design/client/_update/hello/client:foo?A=B << EOF
> > {"_id": "client:foo"}
> > EOF
> foo bar
> And it really updated the document.
> What i expected here is error: conflict because document with such _id
> already existed and i didn't provide _rev to _update handler.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-911) Repeating a doc._id in a _bulk_docs request results in erroneous "Document conflict" error
[
https://issues.apache.org/jira/browse/COUCHDB-911?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13088183#comment-13088183
]
Bob Dionne commented on COUCHDB-911:
I think that's true, you might have a dup in the bulk docs request and both are
rejected because a third with the same id was sent from another client. All
this patch does is match the docs that are sent to couch_db_updater with any
conflict messages that are returned. If you send docs A,B,C,D, and E they will
be processed in this order. I think this is true, even though other clients
might send updates for B and C and they will be grouped in. But the client that
sent A,B,C,D, and E will see any conflicts returned in that order.
Two docs with the same id might have different bodies, .ie. aren't really dups.
It's important to indicate which is rejected and which committed. Currently for
both this case and the case of dups we save the second (because we reverse the
order) and report both rejected, which leaves the database in an inconsistent
state.
> Repeating a doc._id in a _bulk_docs request results in erroneous "Document
> conflict" error
> --
>
> Key: COUCHDB-911
> URL: https://issues.apache.org/jira/browse/COUCHDB-911
> Project: CouchDB
> Issue Type: Bug
> Components: HTTP Interface
>Affects Versions: 1.0
> Environment: Cloudant BigCouch EC2 node
>Reporter: Jay Nelson
>Priority: Minor
> Original Estimate: 48h
> Remaining Estimate: 48h
>
> Repeating an "_id" in a _bulk_docs post data file results in both entries
> being reported as document conflict errors. The first occurrence actual
> inserts into the database, and only the second occurrence should report a
> conflict.
> curl -d '{ "docs": [ {"_id":"foo"}, {"_id","foo"} ] }' -H
> 'Content-Type:application/json' -X POST
> http://appadvice.cloudant.com/foo/_bulk_docs
> [{"id":"foo","error":"conflict","reason":"Document update
> conflict."},{"id":"foo","error":"conflict","reason":"Document update
> conflict."}]
> But the database shows that one new document was actually inserted.
> Only the second occurrence should report conflict. The first occurrence
> should report the "_rev" property of the newly inserted doc.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (COUCHDB-1012) Utility to help plugin developers manage paths
[ https://issues.apache.org/jira/browse/COUCHDB-1012?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13088179#comment-13088179 ] Randall Leeds commented on COUCHDB-1012: I think we're getting carried away. localstatelibdir (db-dir), localstatelogdir (log-dir) should disappear from here. localstatedir is the only variable that matters to autotools[1] and we don't even accept the others as flags to configure. I'd drop pid-file, uri-file and all the autotools stuff because it's not relevant for developing _modules_ for couchdb. It's relevant for building and running couchdb, when the values are either being passed by the packager or set by the operator. Something like --libdir to mean the erlang lib dir for all the erlang modules we install and --configdir to be the directory containing local.d and default.d. That's all developers should need. If developers of plugins want to install documentation of various formats they can do their own autotools dance. The documentation and supporting tooling or whatever else somone might package together with a couchdb module and how they distribute it is not our concern, but unless we provide a way for developers to modify the erlang code path we need them to install to our --libdir. Otherwise, it's just erlang modules that couch can load via its hooks in the .ini system. We shouldn't overthink this. [1] https://www.gnu.org/s/hello/manual/autoconf/Installation-Directory-Variables.html > Utility to help plugin developers manage paths > -- > > Key: COUCHDB-1012 > URL: https://issues.apache.org/jira/browse/COUCHDB-1012 > Project: CouchDB > Issue Type: New Feature > Components: Build System >Reporter: Randall Leeds >Assignee: Noah Slater > Fix For: 1.2 > > Attachments: > 0001-add-couch-config-file-used-to-ease-the-build-of-plug.patch, > 0001-add-couch-config-file-used-to-ease-the-build-of-plug.patch, > 0001-support-pkg-config-for-plugins-COUCHDB-1012.patch > > > Developers may want to write plugins (like GeoCouch) for CouchDB. Many hooks > in the configuration system allow loading arbitrary Erlang modules to handle > various internal tasks, but currently there is no straightforward and > portable way for developers of these plugins to discover the location of the > CouchDB library files. > Two options that have been proposed are to use pkg-config or install a > separate script that could be invoked (e.g. as couch-config --erl-libs) to > discover important CouchDB installation paths. > As far as I know the loudest argument against pkg-config is lack of support > for Windows. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Closed] (COUCHDB-1255) Deleting source db in continuous filtered replication crashes couchdb and prevents restart
[
https://issues.apache.org/jira/browse/COUCHDB-1255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Filipe Manana closed COUCHDB-1255.
--
Resolution: Duplicate
Fix Version/s: 1.1.1
Hi,
Should no longer happen in the branch 1.1.x. You'll get an error message like
the following in the log/consoleIf:
[error] [<0.104.0>] Replication manager, error processing document `testrep1`:
Could not open source database `dba`: {db_not_found,<<"dba">>}
If after trying out the patch still happens, please reopen this ticket.
> Deleting source db in continuous filtered replication crashes couchdb and
> prevents restart
> --
>
> Key: COUCHDB-1255
> URL: https://issues.apache.org/jira/browse/COUCHDB-1255
> Project: CouchDB
> Issue Type: Bug
>Affects Versions: 1.1
> Environment: OSX
>Reporter: Simon Robson
> Fix For: 1.1.1
>
>
> Steps to reproduce:
> curl -X PUT http://user:pass@localhost:5984/dba
> curl -X PUT http://user:pass@localhost:5984/dbb
> curl -X PUT http://user:pass@localhost:5984/dba/_design/testapp -d
> '{"filters": {"rep_filter": "function(doc, req) {return true}"}}' -H
> "Content-Type: application/json"
> curl -X POST http://user:pass@localhost:5984/_replicator -d '{"_id":
> "testrep1", "source": "dba", "target": "http://user:pass@localhost:5984/dbb";,
> "continuous": true, "create_target": true, "filter": "testapp/rep_filter"}'
> -H "Content-Type: application/json"
> # wait long enough for first replication checkpoint
> sleep 10
> curl -X DELETE http://user:pass@localhost:5984/dba
> At this point couch crashes and can't be restarted.
> These issues are related:
> https://issues.apache.org/jira/browse/COUCHDB-1233
> https://issues.apache.org/jira/browse/COUCHDB-1199
> Maybe fixed in 1.1.1 by patch in above issue, but I don't have access to
> confirm.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
