|
|
|
Unfortunately the incredible plan that was designed while the development team was meeting in Stockholm a few years back has been lost. So I'll try to re-construct an new awesome plan/design here :)
The general idea is to: # (optional) build a {{BootstrapServiceRegistry}} # (~ optional) build a {{StandardServiceRegistry}} # instantiate a {{MetadataSources}} object, and tell it about the sources for mapping information # build a {{Metadata}} object (representing processed metadata sources). We get here along a few possible paths, depending on what non-default behavior/settings should be used: ** {{MetadataSources#buildMetadata()}} - uses all defaults for building the {{Metadata}}. What about connection info, or other information we really need? To be fair we don't really *need* the JDBC connection info here; its just nice because we can use it (knowing the dialect) for automatically handling certain mapping stuff (quoting keywords e.g.) ** {{MetadataSources#getMetadataBuilder()}} - used to obtain a {{MetadataBuilder}} that can further control the {{Metadata}} building process. ** {{MetadataSources#getMetadataBuilder(StandardServiceRegistry)}} - used to obtain a {{MetadataBuilder}} that can further control the {{Metadata}} building process given a specific {{StandardServiceRegistry}} # build a SessionFactory via {{Metadata#buildSessionFactory}}
----
h4. Contributors
Contributors contribute various things to the start up of Hibernate:
* {{MetadataSourcesContributor}} - Contract for contributing sources to {{MetadataSources}}. Called by {{MetadataBuilder}}. Adds sources after those explicitly added through {{MetadataSources}} * {{MetadataContributor}} - Contract for contributing bindings to {{Metadata}}. Called by {{Metadata}}. Called after {{MetadataSources}} have been processed (so it has access to the bindings from sources). Envers uses this. * {{ServiceContributor}} - Contract for contributing services. Called by {{StandardServiceRegistryBuilder}} * {{TypeContributor}} - Contract for contributing types. Called by {{Metadata}}. {{Dialect}} is also an implicit {{TypeContributor}} (spatial makes use of this to register db specific geo mapping types).
There was discussion about combining these into a single contract for stuff that supplies lots of types of contributions.
Another consideration is current {{Integrator}}. I think the ideal scenario would be to analyze the types of things contributed by an {{Integrator}} and make explicit contributor contracts (EventListenerContributor e.g.). {{Integrator}} could then be the "single contract" for supplying contributors.
----
h4. Configuration
As a migration path, I'd like to keep {{Configuration}} around at least in the short term. However, certain methods will need to be removed. We could deprecate and "gut" them (remove impl code). But I think ripping off the band-aid might be best here. Thoughts?
Anyway, the methods in question: * (?) getReflectionManager * getClassMappings * getCollectionMappings * getTableMappings * getMappedSuperclassMappings * getMappedSuperclassMappingsCopy * getClassMapping * getCollectionMapping * (?) createMappings * iterateGenerators * generateDropSchemaScript * generateSchemaCreationScript * generateSchemaUpdateScript * generateSchemaUpdateScriptList * validateSchema * getNamedQueries * getNamedProcedureCallMap * getJaccPermissionDeclarations * getRootClassMapping * getImports * getNamedSQLQueries * getSqlResultSetMappings * buildMapping * getFilterDefinitions * iterateFetchProfiles * getNamedEntityGraphs
Further Configuration methods of interest: * buildMappings - we can leave it, depending on the decision above wrt remove versus deprecate/gut. At the least should be deprecated. *
|
|
|
|