Some semi-structured thoughts:

The issue is quite complex and involves several linked layers

1. How to push the info to the dialect

Decide how the data is merged (if mappings are overridden by context) and how it is exposed.

Should we pass the annotations directly, or some other form of metadata?

2. Optionally how to get the info on whether or not a dialect supports a setting

Get a list of supported features for a given datastore provider. In a type-safe way or not.

3. How to let a user define a mapping

Annotation is the natural approach for entity or association specific information. But we also need
a programmatic approach to let people decorrelate these info from the actual object model.
For example, denormalization options could be centralized separately from the domain model.

There is tension between an annotation model, the programmatic model, how it's supposed to be merged and the model as exposed to the dialect.

4. Decide whether or not a setting and a mapping are different things and should be treated differently

Some mappings, especially global ones are close to a setting. Should they be exposed through this facility
or left global like a classic persistence.xml property for example.
A few mapping / settings are quite borderline. But I guess if a setting can be per entity or per property, better expose it.

5. See if layers of mappings should be bundled together or separated across several contracts

We have several layers of mapping:

• per nosql family (generic, key-value based, eventually consistent based, mongodb specific etc)
• per context (global, per entity, per property)
• per use case (global or per session refinement)

We need a facility to offer refinement per session, maybe with named mapping profiles. Reusing the programmatic API makes sense here except if some mappings cannot be overridden (do such exist?)

Each nosql family level might be expressible with specific set interfaces for each. A provider would then extend the ones that make sense. (ie Infinispan would extend the key/value ones.

Note that some settings could be overridden by more specific contexts:

• global level by entity level and entity level by property level
• default mapping by per-use case level

Since there are at least two levels of overriding potentially, that bears the question of what happens when you mix and match