I created a ticket for this at https://tickets.openmrs.org/browse/SXS-5
-Darius On Fri, May 18, 2012 at 6:36 AM, Michael Seaton <[email protected]> wrote: > 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: [email protected] [[email protected]] On Behalf Of Darius Jazayeri [ > [email protected]] > Sent: Friday, May 18, 2012 4:52 AM > To: [email protected] > 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" <[email protected]<mailto: > [email protected]>> 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 > [email protected]<mailto:[email protected]> with > "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. > > [mailto:[email protected]<mailto:[email protected] > >?body=SIGNOFF%20openmrs-devel-l] > ________________________________ > Click here to > unsubscribe<mailto:[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] > _________________________________________ 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]
