Why is buildSessionFactory deprecated in hibernation and why use ServiceRegistry?

Read more about here .

Currently the SessionFactory is created by throwing a bunch of stuff into the config object, stirring it, letting it boil, and then pulling the SessionFactory. Seriously, there are several problems with how we currently work within the Configuration and how we use it to create a SessionFactory: the general problem is that there is no "life cycle" when different pieces of information are available. This is an important omission in several ways:

• Let's consider creating a schema. currently we can't even know the dialect when many db object names are defined. it would be nice because it would allow us to transparently handle table and column names that are also keywords / reserved words in the dialect.
• static type and type-mappings. Because we currently have nothing to cover them. Ideally, an instance of a type should know the SessionFactory it is associated with. Instead, what we have now is changing the API methods quite time consuming to be added to the SessionFactory as a passed parameter whenever it is found to be needed.
• also, most (all?) "static" configuration parameters in Hibernate are currently required because of their use from within these static types; thus, scoping types allow us to also have such configuration parameters (such as byteecode-provider, use of binary streams, etc.). Ideally, what I see is a schema in which users create their own instance of org.hibernate.cfg.Settings (or something similar). In addition, they will apply metadata to some registry (let's call it MetadataRegistry for now). Then, to build the SessionFactory, they will supply these two pieces of information (via the ctor? Through the builder?). An important aspect is that the information in the MetadataRegistry will not be reviewed until this point, which will allow us to ensure thatthat resolution of object names, types, etc. Will have access to runtime settings (and in particular dialect)