Menu
▾
▴
Re: [Springframework-developer] HibernateDaoSupport
|
From: <jue...@we...> - 2004-07-26 13:38:11
|
Colin, I see your point. We could keep setSessionFactory as final, but let it = delegate to a non-final protected = createHibernateTemplate(SessionFactory) method that could be overridden = in subclasses, even allowing to plug in custom HibernateTemplate = subclasses. That's a quite clean and very flexible solution, IMO. I'd be = happy to adapt HibernateDaoSupport, JdoDaoSupport and co accordingly. Let's also not forget that we're talking about a convenience base class = here: For special needs, it's trivial to create a custom base class that = does not derive from HibernateDaoSupport in the first place. We "just" = need to cover 95% of use cases here. I agree that allowCreate=3Dfalse is = quite common, though, so we should cover that; also, setting the = flushMode: createHibernateTemplate would cover both. Juergen -----Original Message----- From: spr...@li... [mailto:spr...@li...]On Behalf Of Colin Sampaleanu Sent: Monday, July 26, 2004 3:16 PM To: spr...@li... Subject: Re: [Springframework-developer] HibernateDaoSupport Juergen, Personally, I do feel the class has somewhat of a 'smell' as it is now,=20 although part of the reason is that setSessionFactory itself is doing=20 work instead of this stuff being done in the init method (I realize this = is to allow the thing to work without the init method ever being=20 called). The issue to me though is the fact that I have seen on a number = of occassions people get burned by the default allowCreate flag being=20 true. They mess up their tx settings, and have no tx, but don't realize=20 it because the sessions are still being created. If instead they were=20 using the flag with a false value (at absolutely no pain for most=20 situations when using HibernateTransactionManager or another tx manger=20 eith HibernateInterceptor), they automatically get an error when their=20 DAO is not running in a tx. So I feel it is important to have some=20 relatively easy way to override this, at least so that some team lead or = architect can enforce this. I think it's not really necessary to have=20 the default HibernateDaoSupport allow setting this by DAOs which derive=20 directly, it's not a big deal to ask people to subclass it to change the = handing of this, and just use that common user variant as their=20 superclass. So taking out the setters and getters is not a big deal. Now = with regards to allowing the default flag handling to be overriden by a=20 subclass though, allowing setSessionFactory to be overriden would work=20 fine, although arguably it's not much cleaner than still having the=20 field there (for the default value) which a subclass can override in a=20 constructor. If setSessionFactory were to be made non-final like this=20 then we need to document much more clearly (javadoc) that that method is = actually responsible for creating a template if none is set, in the=20 default impl. Regards, Colin j=FCrgen h=F6ller [werk3AT] wrote: >Colin, >=20 >I've just had a look at the new "defaultTemplateAllowCreateValue" flag = in HibernateDaoSupport, and I'm frankly not happy with it. We have a = special check whether the HibernateTemplate is self-created etc, = indicating - for me at least - that something is wrong there. I see your = use case, which is worth addressing, but I think the current approach is = not ideal. >=20 >This is not really how our XxxDaoSupport classes are meant to be used. = In the case of HibernateDaoSupport: either pass in a SessionFactory *or* = a preconfigured HibernateTemplate. If you want a default value for = HibernateTemplate's "allowCreate" flag, why not set up a = HibernateTemplate bean in your context, configure it with = "allowCreate"=3Dfalse and pass it to all your DAOs? This would work = nicely with the old HibernateDaoSupport implementation, without any = special checks... >=20 >My two main concerns are 1. consistency, i.e. that JdoDaoSupport and = the others would have to be coded in a similar fashion and 2. future = extensions, i.e. what happens if there's a further flag on = HibernateTemplate that you want to set via your DAO? Particularly in the = latter case, I'm not keen on having that sort of "if-self-created-then" = properties on the DAO: They confuse things, and just apply when passing = in a SessionFactory (not when passing in a HibernateTemplate), which is = not immediately obvious. >=20 >To allow for programmatic setting of such HibernateTemplate properties, = we could turn setSessionFactory non-final, allowing it to override with = a version that builds a custom HibernateTemplate for that = SessionFactory. That would be much cleaner, IMO, and easy to adapt in = JdoDaoSupport and co. Our data access templates and DAO base classes are = among the most popular parts of Spring, so it's important to indicate a = clear strategy there. >=20 >All things considered, I quite strongly believe that we should use to = the old HibernateDaoSupport implementation again, just turning = setSessionFactory non-final to allow for programmatic overriding. For = context-driven configuration, let's recommend to pass in a preconfigured = HibernateTemplate bean. Can I convince you of this? >=20 >Unfortunately, I'm already in a bit of a hurry here: I'd like to - = finally! - get 1.1 RC1 out tomorrow. >=20 >Juergen >=20 > >________________________________ > >Von: spr...@li... im Auftrag = von Colin Sampaleanu >Gesendet: Do 15.07.2004 16:02 >An: spr...@li... >Betreff: Re: [Springframework-developer] HibernateDaoSupport > > > >I don't like that solution, because it will then also affect any >HibernateTemplate that is passed in. The current code does not touch = any >template that is passed in. These changes do not want to modify that >behaviour, but rather allow the default value for allowCreate on _new_ >templates created to be specified. And I think there are two ways that >people would want to play with the flag: either make their own subclass >which sets the flag to false, and that becomes the superclass of all >their DAOs, or alternately, do not use a subclass at all, but in some >(or all) DAOs, specifically set the default value. > >Colin > >j=FCrgen h=F6ller [werk3AT] wrote: > > =20 > >>Colin, >> >>What about simply invoking >> >> getHibernateTemplate().setAllowCreate(false); >> >>in the initDao implementation of your subclass? >> >>Juergen >> >> >>________________________________ >> >>Von: spr...@li... im Auftrag = von Colin Sampaleanu >>Gesendet: Do 15.07.2004 05:34 >>An: spr...@li... >>Betreff: [Springframework-developer] HibernateDaoSupport >> >> >> >>Juergen, >> >>The existing code in HibernateDaoSupport created a HibernateTemplate >>with the allowCreate flag as true by default, and as the >>setSessionFactory method where the template was created was final, = there >>was no way to override this. I have created a protected field called >>defaultTemplateAllowCreateValue (true by default to maintain existing >>behaviour), which a user HibernateDaoSupport subclass may override. >>Additionally, I have added a setter for this default value, so a DAO >>instance can be set to true or false specifically (without having to >>subclass). This value does not affect any HibernateTemplate passed in >>explicitly. >> >>Colin >> =20 >> ------------------------------------------------------- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_id=3D4721&alloc_id=3D10040&op=3Dclick _______________________________________________ Springframework-developer mailing list Spr...@li... https://lists.sourceforge.net/lists/listinfo/springframework-developer |
