I'm about to make OGM run with the new APIs. On a very high level, these things need to be achieved for that:

• Provide a way people can invoke OGM-specific cofiguration APIs (allowing to set options specific to their NoSQL store in a typed manner)
• Return an OgmSessionFactory instead of SessionFactory (we offer some specific things on that contract)
• Auto-apply OGM-specific configuration and settings (mostly properties, but also the ImplicitNamingStrategy)

It would be nice if we can avoid any casts by the user, i.e. they get a typed API which returns the OGM types once they took the "OGM path" during bootstrap.

The first and the second one could be addressed by providing a custom OgmMetadataBuilder contract which a) offers additional OGM-specific methods and b) returns an OgmMetadata which in turn provides access to a OgmSessionFactory (all these contracts would extend their ORM counterparts, or share a base class with commonalities between ORM/OGM).

One issue with that is that MetadataBuilder (an interface) currently is obtained through MetadataSources. The latter seems fine as is though for OGM, so we'd only have to override it in order to let getMetadataBuilder() etc. return the OGM types. Therefore, how about moving getMetadataBuilder() and buildMetadata() from MetadataSources to a separate place:

MetadataSources sources = ...;
MetadataBuilder builder = Bootstrap.getMetadataBuilder( sources );

// or with registry
StandardServiceRegistry registry = Bootstrap.getStandardServiceRegistryBuilder()...build();
MetadataBuilder builder = Bootstrap.getMetadataBuilder( sources, registry );

We then could do it similarly in OGM:

MetadataSources sources = ...;
OgmMetadataBuilder builder = OgmBootstrap.getMetadataBuilder( sources );

The third point from above would be addressed by having our creator methods on OgmBootstrap apply the required settings before returning the builder (or registry in case of property settings) instance.

Another thing I came across are some SQL-specific methods on Metadata (e.g. getSqlFunctionMap(). Maybe we could move these to a Metadata sub-class bootstrapped and exposed by the ORM hierarchy, whereas OGM could have its own Metadata specialization, possibly exposing NoSQL-specific things it may need?

Steve Ebersole, Emmanuel Bernard, Sanne Grinovero, any thoughts?