5:17 p.m.
Hi,
Maybe you could also use a builder for this:
AbstractEntityManagerImpl = AbstractEntityManagerBuilder
.forDelegate(entityManagerFactory)
.contextType(...)
.transactionType(...)
.property("foo", bar)
.property("baz", qux)
.build();
That way new attributes required for creating an AEMI can be added
without breaking existing clients (as long as there is a reasonable
default value for the newly added attributes) and it make usage for a
client easier IMO as one doesn't have to create an Options object
which is then passed to the constructor.
--Gunnar
2012/7/17 Sanne Grinovero <sanne(a)hibernate.org>:
On 17 July 2012 03:57, Steve Ebersole <steve(a)hibernate.org>
wrote:
> 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?
Indeed mayor changes in Hibernate will likely need specific release of
OGM/Search/...
The need for us to extend some core classes is to improve the odds,
specifically thinking about minor releases:
it happened that upgrading some Hibernate ORM 4.1.x to 4.1.y people
would need a different Search version (and a release from our part).
I understand we can't promise this won't happen, I just wish we make
it "unlikely" to need specific versions to be coupled together. I've
seen many users attempting to upgrade the stack updating one component
at a time.
If you can use this "Options" that's great, as it looks like a good
design idea anyway, and I'm happy if you help "improving the odds" of
Search/OGM editions being compatible with next Hibernate releases but
there is no need to push this too far, so don't do this if it turns
out impractical for other reasons. As you say, if this happens between
a JPA 2.0 -> 2.1 it is very likely that compatibility will break for
other reasons anyway.
Cheers,
Sanne
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev