On Mon, 25 Jan 2010 06:12:55 -0300, Emmanuel Bernard
<emmanuel(a)hibernate.org> wrote:
> We've added others in the new
org.hibernate.ejb.AvailableSettings. This
> is a mix of JPA defined settings plus some additional
> Hibernate-EM-specific settings. I like the idea of
> org.hibernate.ejb.AvailableSettings specifically because it consolidates
> all the setting names in a single place.
The "historical" setting repository for HEM is HibernatePersistence. Are
we deprecating it?
I don't think that the plan is to deprecate HibernatePersistence just the
properties
names which were in HibernatePersistence got consolidated in
AvailableSettings.
This way all settings (excluding org.hibernate.cfg.Environment settings)
are not combined
in a single place.
> On Friday on IRC Hardy and I began discussing the idea of
"Setting"s as
> an internal contract that describes how a setting is applied. Take the
> case of EM, there we'd have a series of named Settings that are specific
> to EM. We described a pretty simplistic interface, something like:
> interface EntityManageSetting {
> public void apply(SessionImplementor session, Object value);
> public Object determineValue(SessionImplementor session);
> }
>
> Then the pseudo-code for EM.setProperty becomes:
> public void setProperty(String name, Object value) {
> final EntityManageSetting setting = getSetting( name );
> if ( setting != null ) {
> // recognized setting
> setting.apply( getSessionImplementor(), value );
> }
> //else {
> // setting was not recognized, ignore per spec
> //}
> }
I like this idea of a Setting interface, but I also agree with Emmanuel
that this approach
might be problematic with some settings. Maybe it would help to try to
classify the
properties we are using. What I like about the approach is that it makes
explicit which settings
for example the EM "understands". The determineValue() method would also
help to solve the
problem of reporting the effective settings when em.getProperties is
called.
EMF#setProperty is not a contract, at least in JPA 2: we have removed
it
in the last draft before running final.
If we want to implement that as an extension, I am in favor of applying
the new settings to all the new EM being created from now on and not
affect existing ones.
+1 for me for this approach as well. Seems to make most sense.
--Hardy