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 > _________________________________________ 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]
