[
https://issues.apache.org/jira/browse/COUCHDB-1004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12978306#action_12978306
]
Filipe Manana commented on COUCHDB-1004:
----------------------------------------
I now remember I had the same issue with the new replicator code. I opted for
using always binaries:
https://github.com/fdmanana/couchdb/blob/trunk_new_replicator/src/couchdb/couch_api_wrap.erl#L110
Like this, all the code that uses the output of that function always does
something like:
couch_util:get_value(<<"key">>, List)
Using couch_util:to_existing_atom/1, means that further code doesn't know what
type of key to use: an atom or a binary. The solution would be to do something
like:
couch_util:get_value(mykey, List, couch_util:get_value(<<"mykey">>, List))
But that's a bit too much typing imho
> list_to_existing_atom is too restrictive as used by couch_rep
> -------------------------------------------------------------
>
> Key: COUCHDB-1004
> URL: https://issues.apache.org/jira/browse/COUCHDB-1004
> Project: CouchDB
> Issue Type: Bug
> Components: Replication
> Environment: erlang
> Reporter: Bob Dionne
> Priority: Minor
>
> We'd like to additional information to db_info in BigCouch, such as the Q and
> N constants for a given database. This causes replication to fail when
> replicating from BigCouch to CouchDB due to the use of list_to_existing_atom
> in couch_rep:dbinfo(...
> The claim is that list_to_atom pollutes the atoms table, however superficial
> testing indicates this is not the case, list_to_atom when called repeatedly
> seems to work fine. If this is true then consider reverting
> list_to_existing_atom back to list_to_atom.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
