Problem with 1.9 and Reporting

classic Classic list List threaded Threaded
4 messages Options
Lara Kellett Lara Kellett
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Problem with 1.9 and Reporting

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 [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

1.6ReportDefinition (30K) Download Attachment
1.9ReportDefinition (2K) Download Attachment
Darius Jazayeri-2 Darius Jazayeri-2
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: 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" <[hidden email]> 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 [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]

[hidden email] from OpenMRS Developers' mailing list
Michael Seaton Michael Seaton
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problem with 1.9 and Reporting

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: [hidden email] [[hidden email]] On Behalf Of Darius Jazayeri [[hidden email]]
Sent: Friday, May 18, 2012 4:52 AM
To: [hidden email]
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" <[hidden email]<mailto:[hidden email]>> 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 [hidden email]<mailto:[hidden email]> with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]<mailto:[hidden email]>?body=SIGNOFF%20openmrs-devel-l]
________________________________
Click here to unsubscribe<mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]
Darius Jazayeri-3 Darius Jazayeri-3
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Problem with 1.9 and Reporting

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 <[hidden email]> 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: [hidden email] [[hidden email]] On Behalf Of Darius Jazayeri [[hidden email]]
Sent: Friday, May 18, 2012 4:52 AM
To: [hidden email]
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" <[hidden email]<mailto:[hidden email]>> 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 [hidden email]<mailto:[hidden email]> with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]<mailto:[hidden email]>?body=SIGNOFF%20openmrs-devel-l]
________________________________
Click here to unsubscribe<mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l> from OpenMRS Developers' mailing list

_________________________________________

To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [hidden email] with "SIGNOFF openmrs-devel-l" in the  body (not the subject) of your e-mail.

[mailto:[hidden email]?body=SIGNOFF%20openmrs-devel-l]


[hidden email] from OpenMRS Developers' mailing list
Loading...