Question about uploading resources into DHIS2

Hi all,

From what I am told whatever resources you load into DHIS under Reports > Resources and whether you add them to a dashboard those are stored in a subfolder in the war file folder on the server. When the war is updated all those files are destroyed and thus you don’t have those copies anymore. Any reason why those resources are stored in the war file folder and not in the same location as uploaded files on the dhis2_home or even better in the database itself?

The problem is that you add those documents to a dashboard and if you update the war file they no longer available… best not to have an option to share resources then if you need to reload them every time…

I do understand that DHIS2 has the ability to store files but the use in this case is for example to add manuals or SOPS or guidelines to the system so the file storage is not ideal rather chose to use resources since it is available in DHIS2. We also using it to load user access forms which may not be intended usage but is useful and the reality is that every time the war is updated everything that is uploaded is destroyed – quite a shock…

I must also say that the documentation does not provide clear guideline on how this feature should be used and a warning that anything you load there is stored in the war file?

Regards,

Elmarie Claasen

Hisp logo

Project Manager

Health Information Systems Program

Tel: 041-367 1027

Cell: 082 374 2209

E-mail: elmarie@hisp.org

Skype: elmarie.claasen52

This message and any attachments are subject to a disclaimer published at http://www.hisp.org/policies.html#comms_disclaimer . Please read the disclaimer before opening any attachment or taking any other action in terms of this electronic transmission.
If you cannot access the disclaimer, kindly send an email to disclaimer@hisp.org and a copy will be provided to you. By replying to this e-mail or opening any attachment you agree to be bound by the provisions of the disclaimer.

This message and any attachments are subject to a disclaimer published at http://www.hisp.org/policies.html#comms_disclaimer. Please read the disclaimer before opening any attachment or taking any other action in terms of this electronic transmission. If you cannot access the disclaimer, kindly send an email to disclaimer@hisp.org and a copy will be provided to you. By replying to this e-mail or opening any attachment you agree to be bound by the provisions of the disclaimer.

Hi Elmarie

Just tried this, and in my case they are ending up in $DHIS2_HOME/documents, what is your home set to? are you sure the application can access that folder?

image

···

On Wed, Jul 6, 2016 at 11:23 PM, Elmarie Claasen elmarie@hisp.org wrote:

Hi all,

From what I am told whatever resources you load into DHIS under Reports > Resources and whether you add them to a dashboard those are stored in a subfolder in the war file folder on the server. When the war is updated all those files are destroyed and thus you don’t have those copies anymore. Any reason why those resources are stored in the war file folder and not in the same location as uploaded files on the dhis2_home or even better in the database itself?

The problem is that you add those documents to a dashboard and if you update the war file they no longer available… best not to have an option to share resources then if you need to reload them every time…

I do understand that DHIS2 has the ability to store files but the use in this case is for example to add manuals or SOPS or guidelines to the system so the file storage is not ideal rather chose to use resources since it is available in DHIS2. We also using it to load user access forms which may not be intended usage but is useful and the reality is that every time the war is updated everything that is uploaded is destroyed – quite a shock…

I must also say that the documentation does not provide clear guideline on how this feature should be used and a warning that anything you load there is stored in the war file?

Regards,

Elmarie Claasen

Project Manager

Health Information Systems Program

Tel: 041-367 1027

Cell: 082 374 2209

E-mail: elmarie@hisp.org

Skype: elmarie.claasen52

This message and any attachments are subject to a disclaimer published at http://www.hisp.org/policies.html#comms_disclaimer . Please read the disclaimer before opening any attachment or taking any other action in terms of this electronic transmission.
If you cannot access the disclaimer, kindly send an email to disclaimer@hisp.org and a copy will be provided to you. By replying to this e-mail or opening any attachment you agree to be bound by the provisions of the disclaimer.

This message and any attachments are subject to a disclaimer published at http://www.hisp.org/policies.html#comms_disclaimer. Please read the disclaimer before opening any attachment or taking any other action in terms of this electronic transmission. If you cannot access the disclaimer, kindly send an email to disclaimer@hisp.org and a copy will be provided to you. By replying to this e-mail or opening any attachment you agree to be bound by the provisions of the disclaimer.


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Morten Olav Hansen

Senior Engineer, DHIS 2

University of Oslo

http://www.dhis2.org

As Morten says, the files should be stored under ‘$DHIS2_HOME/documents’. There is no intent to store them in the WAR file itself for production instances. That would be pretty silly. It might be a fallback though (which is probably in place for testing purposes).

In answering your comments on where and how the files are stored:

This is a pretty classic problem in database design. And there certainly is no ‘correct’ way to do it. We’ve elected to keep large binary files out of the DB to avoid bloat (it’s already huge for many DHIS 2 instances).

Most importantly, storing large files in the DB can incur huge storage costs for instances running off of SSDs. Serving files can in those cases be done from a separate (much cheaper) disk or location, which makes a lot of sense. Of course, this has some major drawbacks as well, especially in terms of adding to maintenance complexity. It’s a tradeoff.

image

···

On Wed, Jul 6, 2016 at 6:23 PM, Elmarie Claasen elmarie@hisp.org wrote:

Hi all,

From what I am told whatever resources you load into DHIS under Reports > Resources and whether you add them to a dashboard those are stored in a subfolder in the war file folder on the server. When the war is updated all those files are destroyed and thus you don’t have those copies anymore. Any reason why those resources are stored in the war file folder and not in the same location as uploaded files on the dhis2_home or even better in the database itself?

The problem is that you add those documents to a dashboard and if you update the war file they no longer available… best not to have an option to share resources then if you need to reload them every time…

I do understand that DHIS2 has the ability to store files but the use in this case is for example to add manuals or SOPS or guidelines to the system so the file storage is not ideal rather chose to use resources since it is available in DHIS2. We also using it to load user access forms which may not be intended usage but is useful and the reality is that every time the war is updated everything that is uploaded is destroyed – quite a shock…

I must also say that the documentation does not provide clear guideline on how this feature should be used and a warning that anything you load there is stored in the war file?

Regards,

Elmarie Claasen

Project Manager

Health Information Systems Program

Tel: 041-367 1027

Cell: 082 374 2209

E-mail: elmarie@hisp.org

Skype: elmarie.claasen52

This message and any attachments are subject to a disclaimer published at http://www.hisp.org/policies.html#comms_disclaimer . Please read the disclaimer before opening any attachment or taking any other action in terms of this electronic transmission.
If you cannot access the disclaimer, kindly send an email to disclaimer@hisp.org and a copy will be provided to you. By replying to this e-mail or opening any attachment you agree to be bound by the provisions of the disclaimer.

This message and any attachments are subject to a disclaimer published at http://www.hisp.org/policies.html#comms_disclaimer. Please read the disclaimer before opening any attachment or taking any other action in terms of this electronic transmission. If you cannot access the disclaimer, kindly send an email to disclaimer@hisp.org and a copy will be provided to you. By replying to this e-mail or opening any attachment you agree to be bound by the provisions of the disclaimer.


Mailing list: https://launchpad.net/~dhis2-devs

Post to : dhis2-devs@lists.launchpad.net

Unsubscribe : https://launchpad.net/~dhis2-devs

More help : https://help.launchpad.net/ListHelp

Halvdan Hoem Grelland

Software developer, DHIS 2

University of Oslo

http://www.dhis2.org

Morten and Halvdan,

Thanks for your responses thus far. I will consult our server specialist for input/clarification as I am kind of floundering in the dark here.

Regards,

Elmarie Claasen

Hisp logo

Project Manager

Health Information Systems Program

Tel: 041-367 1027

Cell: 082 374 2209

E-mail: elmarie@hisp.org

Skype: elmarie.claasen52

This message and any attachments are subject to a disclaimer published at http://www.hisp.org/policies.html#comms_disclaimer . Please read the disclaimer before opening any attachment or taking any other action in terms of this electronic transmission.
If you cannot access the disclaimer, kindly send an email to disclaimer@hisp.org and a copy will be provided to you. By replying to this e-mail or opening any attachment you agree to be bound by the provisions of the disclaimer.

···

From: Halvdan Hoem Grelland [mailto:halvdan@dhis2.org]
Sent: 07 July 2016 10:57 AM
To: Elmarie Claasen
Cc: DHIS 2 Developers list
Subject: Re: [Dhis2-devs] Question about uploading resources into DHIS2

As Morten says, the files should be stored under ‘$DHIS2_HOME/documents’. There is no intent to store them in the WAR file itself for production instances. That would be pretty silly. It might be a fallback though (which is probably in place for testing purposes).

In answering your comments on where and how the files are stored:

This is a pretty classic problem in database design. And there certainly is no ‘correct’ way to do it. We’ve elected to keep large binary files out of the DB to avoid bloat (it’s already huge for many DHIS 2 instances).

Most importantly, storing large files in the DB can incur huge storage costs for instances running off of SSDs. Serving files can in those cases be done from a separate (much cheaper) disk or location, which makes a lot of sense. Of course, this has some major drawbacks as well, especially in terms of adding to maintenance complexity. It’s a tradeoff.

On Wed, Jul 6, 2016 at 6:23 PM, Elmarie Claasen elmarie@hisp.org wrote:

Hi all,

From what I am told whatever resources you load into DHIS under Reports > Resources and whether you add them to a dashboard those are stored in a subfolder in the war file folder on the server. When the war is updated all those files are destroyed and thus you don’t have those copies anymore. Any reason why those resources are stored in the war file folder and not in the same location as uploaded files on the dhis2_home or even better in the database itself?

The problem is that you add those documents to a dashboard and if you update the war file they no longer available… best not to have an option to share resources then if you need to reload them every time…

I do understand that DHIS2 has the ability to store files but the use in this case is for example to add manuals or SOPS or guidelines to the system so the file storage is not ideal rather chose to use resources since it is available in DHIS2. We also using it to load user access forms which may not be intended usage but is useful and the reality is that every time the war is updated everything that is uploaded is destroyed – quite a shock…

I must also say that the documentation does not provide clear guideline on how this feature should be used and a warning that anything you load there is stored in the war file?

Regards,

Elmarie Claasen

Hisp logo

Project Manager

Health Information Systems Program

Tel: 041-367 1027

Cell: 082 374 2209

E-mail: elmarie@hisp.org

Skype: elmarie.claasen52

This message and any attachments are subject to a disclaimer published at http://www.hisp.org/policies.html#comms_disclaimer . Please read the disclaimer before opening any attachment or taking any other action in terms of this electronic transmission.
If you cannot access the disclaimer, kindly send an email to disclaimer@hisp.org and a copy will be provided to you. By replying to this e-mail or opening any attachment you agree to be bound by the provisions of the disclaimer.

This message and any attachments are subject to a disclaimer published at http://www.hisp.org/policies.html#comms_disclaimer. Please read the disclaimer before opening any attachment or taking any other action in terms of this electronic transmission. If you cannot access the disclaimer, kindly send an email to disclaimer@hisp.org and a copy will be provided to you. By replying to this e-mail or opening any attachment you agree to be bound by the provisions of the disclaimer.


Mailing list: https://launchpad.net/~dhis2-devs
Post to : dhis2-devs@lists.launchpad.net
Unsubscribe : https://launchpad.net/~dhis2-devs
More help : https://help.launchpad.net/ListHelp

Halvdan Hoem Grelland

Software developer, DHIS 2

University of Oslo

http://www.dhis2.org

This message and any attachments are subject to a disclaimer published at http://www.hisp.org/policies.html#comms_disclaimer. Please read the disclaimer before opening any attachment or taking any other action in terms of this electronic transmission. If you cannot access the disclaimer, kindly send an email to disclaimer@hisp.org and a copy will be provided to you. By replying to this e-mail or opening any attachment you agree to be bound by the provisions of the disclaimer.