see on GitHub

Global Identifier Generation Conventions

FindCollectionName

Documents that have the same @collection metadata belong to the same collection on the server side. Collection names are also used to build document identifiers.

conventions.findCollectionName =
    type => // function that provides the collection name based on the entity type 

TransformClassCollectionNameToDocumentIdPrefix

Collection names determined by recently described convention functions aren't directly used as prefixes in document identifiers. There is a convention function called transformClassCollectionNameToDocumentIdPrefix() which takes the collection name and produces the prefix:

conventions.transformClassCollectionNameToDocumentIdPrefix =
    collectionName => // transform the collection name to the prefix of an identifier, e.g. [prefix]/12

Its default behavior is that for a collection which contains one upper character it simply converts it to lower case string. Users would be transformed into users. For collection names containing more upper characters there will be no change. The collection name: LineItems would output the following prefix: LineItems.

FindJsTypeName and FindJsType

In the metadata of all documents stored by RavenDB Node.js Client, you can find the following property which specifies the client-side type. For instance:

{
    "Raven-Node-Type": "Customer"
}

This property is used by RavenDB client to perform a conversion between a JS object and a JSON document stored in a database. A function responsible for retrieving the JS type of an entity is defined by findJsTypeName() convention:

conventions.findJsTypeName = 
    type => // determine the type name based on type

To properly perform the reverse conversion that is from a JSON result into a JS object, we need to retrieve the JS type from the Raven-Node-Type metadata:

conventions.findJsType((id, doc) => {
        const metadata = doc["@metadata"];
        if (metadata) {
            const jsType = metadata["Raven-Node-Type"];
            return this.getJsTypeByDocumentType(jsType);
        }

        return null;
});

FindIdentityPropertyNameFromCollectionName

It can happen that sometimes the results returned by the server don't have identifiers defined (for example if you run a projection query) however they have @collection in metadata.

To perform the conversion into a JS object, a function that finds the identity property name for a given collection name is applied:

conventions.findIdentityPropertyNameFromCollectionName =
    collectionName => "id";

IdentityPartsSeparator

By default, convention document identifiers have the following format: [collectionName]/[identityValue]-[nodeTag]. The slash character (/) separates the two parts of an identifier. You can overwrite it by using IdentityPartsSeparator convention. Its default definition is:

conventions.identityPartsSeparator = "/";

FindCollectionNameForObjectLiteral

This convention is not defined by default. It's only useful when using object literals as entities. It defines how the client obtains a collection name for an object literal. If it's undefined object literals stored with session.store() are going to land up in @empty collection having a UUID for an ID.

For instance here's mapping of the category field to collection name:

conventions.findCollectionNameForObjectLiteral = 
    entity => entity["category"]; 
    // function that provides the collection name based on the entity object