You are currently browsing legacy 4.0 version of documentation. Click here to switch to the newest 4.2 version.

We can help you with migration to the latest RavenDB

Contact Us Now
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.setFindCollectionName(
    clazz -> // function that provides the collection name based on the entity class

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.setTransformClassCollectionNameToDocumentIdPrefix(
    collectionName -> // transform the collection name to the prefix of a 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.

FindJavaClassName and FindJavaClass

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

{
    "Raven-Java-Type": "com.example.Customer"
}

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

conventions.setFindJavaClassName(
    clazz -> // use reflection to determinate the type
// endregion
""
);

//region find_clr_type
conventions.setFindJavaClass((id, doc) -> {
    return Optional.ofNullable((ObjectNode) doc.get(Constants.Documents.Metadata.KEY))
        .map(x -> x.get(Constants.Documents.Metadata.RAVEN_JAVA_TYPE))
        .map(x -> x.asText())
        .orElse(null);
});

To properly perform the revert conversion that is from a JSON result into a Java object, we need to retrieve the Java class from the Raven-Java-Type metadata:

conventions.setFindJavaClass((id, doc) -> {
    return Optional.ofNullable((ObjectNode) doc.get(Constants.Documents.Metadata.KEY))
        .map(x -> x.get(Constants.Documents.Metadata.RAVEN_JAVA_TYPE))
        .map(x -> x.asText())
        .orElse(null);
});

FindIdentityProperty

The client must know where in your entity an identifier is stored to be properly able to transform it into JSON document. It uses the FindIdentityProperty convention for that. The default and very common convention is that a property named Id is the identifier, so is the default one:

conventions.setFindIdentityProperty(fieldInfo -> "Id".equals(fieldInfo.getName()));

You can provide a customization based on the FieldInfo parameter to indicate which property or field keeps the identifier. The client will iterate over all object properties and take the first one according to the defined predicate.

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 Java object, a function that finds the identity property name for a given entity name is applied:

conventions.setFindIdentityPropertyNameFromCollectionName(
    collectionName -> "Id"
);

IdentityPartsSeparator

According to the 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.setIdentityPartsSeparator("/");