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 <sa...@hibernate.org>:
> On 17 July 2012 03:57, Steve Ebersole <st...@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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
