I have not yet looked into this yet at all, but my guess is that this is due to the fact that we now set uuids on OpenmrsObjects when they are instantiated, rather than when they are saved to the database independently. I am guessing that the Xstream Serializer is serializing the full nested definitions _including_ the uuid, and then when it tries to deserialize this it is looking at the uuid attribute and if it is present it is trying to load the nested definition from the database, and if it is absent it is constructing it from the serialized data. So our xstream serializer is assuming that the presence of a uuid on the definition indicates that it is independently persisted. This is where we will likely need to make the fix...
Mike ________________________________________ From: dev@openmrs.org [dev@openmrs.org] On Behalf Of Darius Jazayeri [djazay...@gmail.com] Sent: Friday, May 18, 2012 4:52 AM To: openmrs-deve...@listserv.iupui.edu Subject: Re: [OPENMRS-DEV] Problem with 1.9 and Reporting Off the top of my head I think we introduced a default serialize in core. Which reporting should not be using, but maybe something is wacky there. -Darius (by phone) On May 18, 2012 1:43 AM, "Lara Kellett" <lkell...@pih.org<mailto:lkell...@pih.org>> wrote: Hi, PIH Rwanda is planning on upgrading to openMRS 1.9 (from 1.6) in June of this year. We are currently investigating an issue with 1.9 (we are testing against RC3) and the Reporting framework (latest version). We are currently investigating the issue, but this one is an absolute show stopper for us and will prevent us from upgrading, so if anyone has any suggestions that would be greatly appreciated. Currently we create our report definitions in code and save the whole report definition without saving the individual components of the report definition (because we use sync to propagate our report definitions to child servers, so it makes life a lot easier if there is only one row in the serialized object table that needs to be propagated, rather than rows for each individual indicator etc). We currently use the ReportDefinitionService saveDefinition method to save the whole report definition. This works fine for 1.6, however running the same code (and versions of the reporting framework) don't work for 1.9. In 1.9 instead of objects like the DataSetDefinitions and Cohorts being serialized as part of the report definition, instead they are referenced within the report definition as if they have been saved independently (which they have not been). This means that the report definition saves just fine, however doesn't run because it can't find the necessary objects it references with the definition. I have attached a copy of the content of the serialized_data column in the serialized object for the report definition as it is saved in 1.6 versus 1.9 so that you can compare the difference in behavior. If anyone has any idea what has changed with the serialization or hibernate interceptors etc which could explain the behavior we are seeing, it would definitely help us out. Thanks, Lara Kellett IMB (PIH) Rwanda _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to lists...@listserv.iupui.edu<mailto:lists...@listserv.iupui.edu> with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:lists...@listserv.iupui.edu<mailto:lists...@listserv.iupui.edu>?body=SIGNOFF%20openmrs-devel-l] ________________________________ Click here to unsubscribe<mailto:lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to lists...@listserv.iupui.edu with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:lists...@listserv.iupui.edu?body=SIGNOFF%20openmrs-devel-l]
