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?
--
st...@hibernate.org
http://hibernate.org
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
