[ https://issues.apache.org/jira/browse/COUCHDB-1004?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12978513#action_12978513 ]
Adam Kocoloski commented on COUCHDB-1004: ----------------------------------------- The proposed solution, but I think you're overcomplicating matters with the code snippet couch_util:get_value(mykey, List, couch_util:get_value(<<"mykey">>, List)) In that example the 'mykey' atom is already in the module, and the module is already loaded, so you know that couch_util:to_existing_atom/1 will give you an atom. There's no need to check for the binary version. > 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 > Attachments: COUCHDB-1004.patch > > > 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.