anchor.diff:  certain nature, how to map data. Document-oriented data stores encourage
   an entity-as-document pattern where embedded data structures could be
   stored within the document itself. Key-value data stores allow different
  -approaches, e. g. storing an entity as JSON document or event storing
  +approaches, e.g. storing an entity as JSON document or event storing
   individual key-value pairs that map the entity within a hash table
   data structure. Hibernate OGM allows multiple dialects per data store
   and users may choose the most appropriate one.
  
positive.code: 
  ==== Entities
  
  Entities are seen by a dialect as `Tuple`. A `Tuple` may contain a
  snapshot (that`s the persistent view of the data), a set of
  key-value pairs that carry the actual data, and a list of operations
  to apply onto the original snapshot. Tuple keys use dot-path
  property identifiers to indicate nesting. That comes handy when working
  with document stores because you can build a document structure based on that details.
  
  
  ==== Associations
  
  The least NoSQL data stores have built-in support for associations
  between entities (unless you're using a graph database). Associations
  are kind of artificial. Association data can be stored within the
  entity itself or externally (as own documents or relation items).
  
  
  ==== Configuration
  
negative.code: 
  === How to build support for a data store
  
  [TIP]
  .Advanced section
  ====
  This is an advanced subject, feel free to skip this section if you are not building a data store.
  ====
  
  Hibernate OGM supports various data stores by abstracting them
  with `DatastoreProvider` and `GridDialect`. The supported features vary between data stores,
  and dialects do not have to implement all features. Hibernate OGM implements a TCK
  