[SERVER-34744] Improve handling of non-ascii collection names Created: 30/Apr/18  Updated: 27/Oct/23  Resolved: 28/May/21

Status: Closed
Project: Core Server
Component/s: Storage
Affects Version/s: None
Fix Version/s: None

Type: Bug Priority: Major - P3
Reporter: Alexander Gorrod Assignee: Gregory Wlodarek
Resolution: Gone away Votes: 0
Labels: NYC
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
Depends
Operating System: ALL
Steps To Reproduce:

The following test code triggers a failure when it gets to 0x7f:

(function() {                                                                   
    "use strict";                                                               
                                                                                
    let illegal_names = new Set();                                              
    illegal_names.add("$");                                                     
    illegal_names.add(".");                                                     
                                                                                
    function testCreateCollectionWithName(coll_name) {                          
        // Cleanup from previous runs                                           
        let coll = db.getCollection(coll_name);                                 
                                                                                
        // We should be able to create a collection with any UTF8 name          
        assert.commandWorked(db.createCollection(coll_name));                   
        coll = db.getCollection(coll_name);                                     
        coll.insert( { x : 1 } );                                               
        coll.findOne();                                                         
    }                                                                           
                                                                                
    for (var i = 1; i < 256; i++) {                                             
        print("Name: " + i + " code: " + String.fromCharCode(i));               
        if (!illegal_names.has(String.fromCharCode(i))) {                       
            testCreateCollectionWithName(String.fromCharCode(i));               
        }                                                                       
    }                                                                           
})();      

 

Sprint: Execution Team 2019-09-23, Execution Team 2019-10-07, Execution Team 2021-06-14
Participants:
Linked BF Score: 21

 Description   

Creating a collection with a UTF8 character out of the ASCII range can result in an unhelpful error. For example, creating a collection called '\x7f' (i.e: the delete character), results in the following error message:

WT_SESSION.create: Error parsing 'type=file,internal_page_max=16k,leaf_page_max=16k,checksum=on,prefix_compression=true,block_compressor=,,,,key_format=u,value_format=u,app_metadata=(formatVersion=8,infoObj={ "v" : 2, "key" : { "_id" : 1 }, "name" : "_id_", "ns" : "test." }),log=(enabled=true)' at offset 237: Unexpected character: Invalid argument 

MongoDB should handle such collection names more elegantly. Either disallowing them similar to $ and {{.}}or allowing their creation without error.



 Comments   
Comment by Gregory Wlodarek [ 28/May/21 ]

Closing this as it is no longer reproducible.

Comment by Brian Lane [ 17/May/21 ]

Putting this back onto execution backlog for review - if this is still not reproducible. Should be ok to close IMHO.

Comment by Louis Williams [ 10/Sep/19 ]

alexander.gorrod I'm unable to reproduce this on master or 4.2, only 4.0. Could something have changed in this code such that this is no longer an issue? If so, is this still something we still should still fix in MongoDB?

Comment by Eric Milkie [ 19/Aug/19 ]

I think it might be difficult to support such characters in collection names so I think we should consider prohibiting them.

Generated at Thu Feb 08 04:37:42 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.