[hibernate-dev] Fwd: Design : delegates and constructors

[Gunnar Morling]

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 at hibernate.org>:
> On 17 July 2012 03:57, Steve Ebersole <steve at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev