[hibernate-dev] Design : delegates and constructors

Steve Ebersole steve at hibernate.org
Mon Jul 16 22:57:16 EDT 2012


Design question on how we want to handle this notion of delegates that 
ogm, search, etc extend and constructors...

Specifically the notion that Sanne has asked for where ORM provides 
implementations of stuff that OGM, Search, etc can just extend.  So, for 
example, AbstractEntityManagerImpl.  AbstractEntityManagerImpl defines a 
(what I call) "strict verbose" constructor.  It takes 4 constructor 
args.  However, now take the case of JPA 2.1 where there is a new 
argument (via new overloaded method) for EM opening (new 
SynchronizationType enum) that we will need to pass along to the 
constructor of AbstractEntityManagerImpl.  This is where, IMO, this 
concept of delegates starts to break down *as we generally define ctors 
today*.  IMO, for this notion of delegates to work as intended, I think 
we needs to provide "bundled" constructor forms.

Again, taking AbstractEntityManagerImpl as the example, today we have:

protected AbstractEntityManagerImpl(
         EntityManagerFactoryImpl entityManagerFactory,
         PersistenceContextType type,
         PersistenceUnitTransactionType transactionType,
         Map properties) {
     ...
}


Leaving aside the passing of a Map for now...

What I think works best in terms of maintaining the intention of these 
delegates is:

protected AbstractEntityManagerImpl(
         AbstractEntityManagerImpl.Options options,
         Map properties) {
     ...
}

or maybe even:

protected AbstractEntityManagerImpl(
         EntityManagerFactoryImpl entityManagerFactory,
         AbstractEntityManagerImpl.Options options,
         Map properties) {
     ...
}


Where Options contains the things AbstractEntityManagerImpl needs to 
initialize itself.  Currently that would be 'type' and 
'transactionType', but JPA 2.1 would add 'synchronizationType' as well. 
  The point though is that OGM, Search etc would not need to be changed 
at all here if the constructor had been defined to accept 
AbstractEntityManagerImpl.Options before and we added 
'synchronizationType' in implementation of JPA 2.1.


Or is moving from JPA 2.0 to 2.1 going to warrant changes in OGM, Search 
anyway that circumventing constructor signature changes is irrelevant?

-- 
steve at hibernate.org
http://hibernate.org



More information about the hibernate-dev mailing list