[hibernate-dev] EMF / EM properties

[Hardy Ferentschik]

On Mon, 25 Jan 2010 06:12:55 -0300, Emmanuel Bernard  
<emmanuel at 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