I've found a way to have the advice around @Transactional so we don't need to change anything in Visits.
Anyway, I don't think we should move @Transactional to the DAO layer. In general it's the service layer that defines units of work that should be transactional. If you have multiple calls to DAO in a service method, you will want to have @Transactional in the service method anyway. -Rafal On 24 February 2012 03:11, Darius Jazayeri <[email protected]> wrote: > Moving this to the dev list. > > Wyclif, I assume that you mean from HibernateVisitDAO to > VisitServiceImpl... > > So, in the long run, we need to move the transactional annotations off of > the service interface. I'd argue that they should go to the concrete DAO, > and only on the methods that actually hit the database. The alternative > would be to move them to the ServiceImpl. > > That said, I'm fine if we want to move them from HibernateVisitDAO up to > the VisitService *interface* for consistency, so that we can refactor *all > * our services later. But what's the argument for moving it from the > HibernateDAO to the ServiceImpl? > > Ideally Rafal will quickly figure out how to move the recent advice code > he wrote so it's triggered by any @Transactional method anywhere, and this > will be moot. > > -Darius > > > On Thu, Feb 23, 2012 at 5:58 PM, Wyclif Luyima <[email protected]> wrote: > >> Hi guys, >> >> @Daniel, we need to move the @Transanctional annotations from >> HibernateVisitDao to ConceptServiceImpl before cutting the 1.9 RC >> >> Wyclif >> >> >> >> > ------------------------------ > Click here to > unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from > OpenMRS Developers' mailing list _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
