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

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&gt;: > On 17 July 2012 03:57, Steve Ebersole <steve(a)hibernate.org&gt; 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 _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev