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]

Reply via email to