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

[Steve Ebersole]

Yep, thats definitiey a possibility as well.  We have moved to builder 
pattern in lots of other places.

On 07/17/2012 05:17 PM, Gunnar Morling wrote:
> 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
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

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