Yes, lets move these to the ServiceImpl. Do we have a ticket somewhere to move the rest of our transaction annotations from interface to impl?
Ben On Fri, Feb 24, 2012 at 9:55 AM, Wyclif Luyima <[email protected]> wrote: > @Rafal, i agree with what you are saying, so we should move them from > HibernateVisitDao to VisitServiceImpl? > > Wyclif > > > > On Fri, Feb 24, 2012 at 5:15 AM, Rafal Korytkowski <[email protected]>wrote: > >> 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 >> >> >> ------------------------------ >> Click here to >> unsubscribe<[email protected]?body=SIGNOFF%20openmrs-devel-l>from >> OpenMRS Developers' mailing list >> > > ------------------------------ > 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]
