Sanne Grinovero commented on Bug OGM-208

1. How to push the info to the dialect
...
Should we pass the annotations directly, or some other form of metadata?

Downside of committing to the annotations:

  • unclear if we're going to be shielded from them (jandex/whatever..)
  • when the source is programmatic(/XML/other..) I'd be glad to avoid facing the synthetic creation of annotations, especially as each datastore contributor would need to face it.

On the other hand, I don't see how an alternative can be typesafe.

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.

I'm thinking if we can re-map the other configuration source all to the DSL definition: if the DSL defines standard bean setters for the option, we invoke them?

Let's assume the Annotations have the meta-annotation you hinted about. So core can find out which annotations are relevant to OGM (as a whole), and then try match annotation to DSL methods via the meta-annotation?
We'd need to use options on the meta-annotation to specify how the various options of the Annotation are to be mapped on the DSL.

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.

For me the most important aspect is to make it very clear which setting is going to prevail in case of multiple (conflicting) definitions.
I guess the list is (last overrides):

  1. global options
  2. XML
  3. annotations
  4. programmatic
  5. runtime: session
  6. runtime: statement
    ?
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators.
For more information on JIRA, see: http://www.atlassian.com/software/jira