I have to admit that you lost me. Could you give some code examples of what's not possible in CouchDB and what alternative you have used?

AFAICS, CouchDB uses Strings as id, i.e. you can't use an embedded document as we do for MongoDB for composite ids:

{ 
    "_id" : { 
        "author" : "Guillaume",
        "title" : "There are more than 20 JUGs in France" 
    },
    "content" : "Great! Congratulations folks",
    "labels" : [  {  "id" : NumberLong(5) } ] 
}

Instead, the CouchDB dialect concatenates the id attribute name(s) and value(s) like this:

{
   "_id": "News:newsId.author_newsId.title_:Guillaume_There are more than 20 JUGs in France_",
   "_rev": "1-bcfae27085f38d0d8596fb97558cd130",
   "type": "CouchDBEntity",
   "tableName": "News",
   "content": "Great! Congratulations folks",
   "newsId": {
       "author": "Guillaume",
       "title": "There are more than 20 JUGs in France"
   }
}

The id attributes are stored additionally in their natural form. We could retrieve these from the id, but I thought considering searches it makes sense to keep them as such (same for the table name). We might consider omitting the attribute name within the concatenation for the default case of a single id property.