redesign SessionFactory building
--------------------------------
Key: HHH-2578
URL:
http://opensource.atlassian.com/projects/hibernate/browse/HHH-2578
Project: Hibernate Core
Issue Type: Improvement
Components: core
Reporter: Steve Ebersole
Assignee: Steve Ebersole
Priority: Critical
Fix For: 4.0.0.Alpha3
Currently a SessionFactory is built by throwing a bunch of stuff into a Configuration
object, stirring it, letting it come to a boil, and then pulling out the SessionFactory.
In seriousness, there are a few problems with the way we currently operate within a
Configuration and how we use it to build a SessionFactory:
The general issue that there is no "lifecycle" to when various pieces of
information will be available. This is an important omission in a number of ways:
1) consider schema generation. currently we cannot even know the dialect when a lot of
db object names are being determined. this would be nice because it would allow us to
transparently handle table/column names which are also keywords/reserved-words in the
dialect, for example.
2) static-ness of types and the type-mappings. Because we currently have nothing to
which to scope them. Ideally a type instance would be aware of the SessionFactory to
which it is bound. Instead, what we have now is to change API methods quite a lot of the
time to add in the SessionFactory as a passed parameter whenever it is discovered that it
is needed.
3) also, most (all?) of the "static" configuration parameters in Hibernate are
currently required to be so because of their use from within these static types; thus
scoping types would allow us to also scope those config parameters (things like
bytecode-provider, use of binary streams, etc).
Ideally what I see happening is a scheme where users build a org.hibernate.cfg.Settings
(or something similiar) instance themselves. Additionally they would apply metadata to a
registry of some sort (lets call it MetadataRegistry for now). Then in order to build a
SessionFactory, they would supply these two pieces of information (via ctor? via
builder?). The important aspect though is that the information in MetadataRegistry would
not be dealt with until that point in time, which would allow us to guarentee that
resolving schema object names, types, etc would have access to the runtime Settings (and
specifically the dialect)
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: