Yeah, I look for things like this that wouldn't work with sync when I code review trunk tickets. I was never worried. ;-)
On Thu, Sep 15, 2011 at 9:56 PM, Jeremy Keiper <[email protected]> wrote: > The sad truth here is that I totally forgot the code I wrote. > > > Jeremy Keiper > OpenMRS Core Developer > AMPATH / IU-Kenya Support > > > On Thu, Sep 15, 2011 at 2:55 PM, Jeremy Keiper <[email protected]> wrote: > >> By golly, there *is* a UUID on the table, and it *is* apparently being >> persisted by calling saveOrUpdate(). You must have looked at that before >> answering! Okay, so that allays my fears of Sync ignoring Form Resources. >> I am still concerned that the Metadata Sharing Module will not pick up on >> them, but that is not a core concern. Thanks! >> >> >> Jeremy Keiper >> OpenMRS Core Developer >> AMPATH / IU-Kenya Support >> >> >> On Thu, Sep 15, 2011 at 9:20 AM, Ben Wolfe <[email protected]> wrote: >> >>> If there is a form_resource.uuid and the form_resource object is being >>> persisted by doing a hibernate session.saveOrUpdate(formResource) then it >>> will sync just fine. >>> >>> Ben >>> >>> >>> On Thu, Sep 15, 2011 at 3:58 PM, Jeremy Keiper <[email protected]>wrote: >>> >>>> In that case, Sync will definitely not handle Form Resources. >>>> >>>> The work that I did for https://tickets.openmrs.org/browse/TRUNK-292 >>>> implements >>>> a basic POJO that is only useful inside service methods, and the data is >>>> stored and retrieved only through service methods. I would much rather >>>> attach those resources to the Form object so they can be handled better. >>>> >>>> However, this could become a slippery slope; attaching multiple >>>> potentially massive byte[] objects to all Forms may be a bad idea. I'm >>>> running into a similar situation just trying to expose FormEntryXsn to the >>>> Metadata Sharing Module. The server sits and spins indefinitely trying to >>>> load XSN objects and throw them to the controller. In order to do anything >>>> with XSNs in a JSP, I had to proxy them through objects that ignore the >>>> data >>>> property. >>>> >>>> So, I don't know what the right approach is ... but I feel like we need >>>> to do something so that Form Resources will be recognized and handled by >>>> the >>>> Sync Module. Ben, is there something I can add to Sync Module as a special >>>> handler for Forms? >>>> >>>> Jeremy Keiper >>>> OpenMRS Core Developer >>>> AMPATH / IU-Kenya Support >>>> >>>> >>>> On Thu, Sep 15, 2011 at 3:37 AM, Ben Wolfe <[email protected]> wrote: >>>> >>>>> Sync does not use the save* methods. If a module object extends >>>>> OpenmrsObject and persists a uuid then it is sync'able. >>>>> https://wiki.openmrs.org/display/docs/Sync+Module+Technical+Overview >>>>> >>>>> Ben >>>>> >>>>> On Thu, Sep 15, 2011 at 6:25 AM, Burke Mamlin <[email protected]> >>>>> wrote: >>>>> > Sounds right. I didn't realize we were storing form resources in a >>>>> hacky >>>>> > way. :-/ >>>>> > >>>>> > -Burke >>>>> > On Wed, Sep 14, 2011 at 11:03 PM, Jeremy Keiper wrote: >>>>> >> >>>>> >> Guys, does sync hook in on save*() or on a more basic level with >>>>> >> hibernate? I think the hacky way we store form resources may allow >>>>> sync to >>>>> >> ignore them. >>>>> >> >>>>> >> I'd like to reconsider the oo approach here, akin to *Attributes ... >>>>> and >>>>> >> this will help with picking up form resources when selecting forms >>>>> to export >>>>> >> in the metadata sharing module. >>>>> >> >>>>> >> What do you all think? >>>>> >> >>>>> >> Jer >>>>> > >>>>> > ________________________________ >>>>> > Click here to unsubscribe 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] >>>>> >>>> >>>> ------------------------------ >>>> 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]
