Inconsistency between schema and api ?

Support - Assistance technique
1

Hello!

I’m making a new DHIS2 App and so make use of the API through d2. I think I found an inconsistency between the schema as exposed under api/schemas and the real field returned.

Having access to the schema is very handy to directly know for example which field to show & how (as we have access to their property types).

There are similar situation for OU (organisationUnitGroups vs just “groups”) and probably other.

Is it something I’m missing or is that a mistake? If this is a bug, let me know if I can fill a PR (with some direction from the team).

Thanks,

Martin

···

**Martin Van Aken - **Freelance Enthusiast Developer

Mobile : +32 486 899 652

Follow me on Twitter : @martinvanaken

Call me on Skype : vanakenm

Hang out with me : martin@joyouscoding.com

Contact me on LinkedIn : http://www.linkedin.com/in/martinvanaken

Company website : www.joyouscoding.com

2

Hi Martin,

this is correct and a good observation.

If you look in the source code you can see that we have specified a JSON field name directly on the get method:

@JsonProperty( "organisationUnits" )

https://github.com/dhis2/dhis2-core/blob/master/dhis-2/dhis-api/src/main/java/org/hisp/dhis/organisationunit/OrganisationUnitGroup.java

This was done to improve on a bad naming choice (“members”) in the past and to expose a more sensible name in the API. This is then reflected in the schemas API as you observed. We hope to change the Java property name in the future but it requires a bit of refactoring.

You can get the name of collections as they are actually rendered in the API through the “collectionName” schema property in the mean time. You could say that we should have a dedicated consistent schema property for the “API field”, we could perhaps work on that.

best,

Lars

···

On 6 January 2018 at 14:26, Martin Van Aken martin@joyouscoding.com wrote:

Hello!

I’m making a new DHIS2 App and so make use of the API through d2. I think I found an inconsistency between the schema as exposed under api/schemas and the real field returned.

Having access to the schema is very handy to directly know for example which field to show & how (as we have access to their property types).

There are similar situation for OU (organisationUnitGroups vs just “groups”) and probably other.

Is it something I’m missing or is that a mistake? If this is a bug, let me know if I can fill a PR (with some direction from the team).

Thanks,

Martin

–
**Martin Van Aken - **Freelance Enthusiast Developer

Mobile : +32 486 899 652

Follow me on Twitter : @martinvanaken

Call me on Skype : vanakenm

Hang out with me : martin@joyouscoding.com

Contact me on LinkedIn : http://www.linkedin.com/in/martinvanaken

Company website : www.joyouscoding.com

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

–

Lars Helge Øverland

Lead developer, DHIS 2

University of Oslo

Skype: larshelgeoverland

lars@dhis2.org

http://www.dhis2.org

3

Hello,

Thanks for the clarification. So, I can rely on the fact that the schema property “collectionName” will be consistent with the actual object field, correct?

Just for my curiosity/understanding - while I’m all for API stability (and not breaking stuff or let say break it carefully), I fail to see how updating the schema to be consistent would actually break anything ?

Matin

···

On Sat, Jan 6, 2018 at 2:55 PM, Lars Helge Øverland lars@dhis2.org wrote:

Hi Martin,

this is correct and a good observation.

If you look in the source code you can see that we have specified a JSON field name directly on the get method:

@JsonProperty( "organisationUnits" )

https://github.com/dhis2/dhis2-core/blob/master/dhis-2/dhis-api/src/main/java/org/hisp/dhis/organisationunit/OrganisationUnitGroup.java

This was done to improve on a bad naming choice (“members”) in the past and to expose a more sensible name in the API. This is then reflected in the schemas API as you observed. We hope to change the Java property name in the future but it requires a bit of refactoring.

You can get the name of collections as they are actually rendered in the API through the “collectionName” schema property in the mean time. You could say that we should have a dedicated consistent schema property for the “API field”, we could perhaps work on that.

best,

Lars

–

On 6 January 2018 at 14:26, Martin Van Aken martin@joyouscoding.com wrote:

Hello!

I’m making a new DHIS2 App and so make use of the API through d2. I think I found an inconsistency between the schema as exposed under api/schemas and the real field returned.

Having access to the schema is very handy to directly know for example which field to show & how (as we have access to their property types).

There are similar situation for OU (organisationUnitGroups vs just “groups”) and probably other.

Is it something I’m missing or is that a mistake? If this is a bug, let me know if I can fill a PR (with some direction from the team).

Thanks,

Martin

–
**Martin Van Aken - **Freelance Enthusiast Developer

Mobile : +32 486 899 652

Follow me on Twitter : @martinvanaken

Call me on Skype : vanakenm

Hang out with me : martin@joyouscoding.com

Contact me on LinkedIn : http://www.linkedin.com/in/martinvanaken

Company website : www.joyouscoding.com

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

Lars Helge Øverland

Lead developer, DHIS 2

University of Oslo

Skype: larshelgeoverland

lars@dhis2.org

http://www.dhis2.org

–

**Martin Van Aken - **Freelance Enthusiast Developer

Mobile : +32 486 899 652

Follow me on Twitter : @martinvanaken

Call me on Skype : vanakenm

Hang out with me : martin@joyouscoding.com

Contact me on LinkedIn : http://www.linkedin.com/in/martinvanaken

Company website : www.joyouscoding.com

4

BTW, I did the test with the collectionName & it works, thanks!

···

On Sun, Jan 7, 2018 at 2:06 PM, Martin Van Aken martin@joyouscoding.com wrote:

Hello,

Thanks for the clarification. So, I can rely on the fact that the schema property “collectionName” will be consistent with the actual object field, correct?

Just for my curiosity/understanding - while I’m all for API stability (and not breaking stuff or let say break it carefully), I fail to see how updating the schema to be consistent would actually break anything ?

Matin

–

On Sat, Jan 6, 2018 at 2:55 PM, Lars Helge Øverland lars@dhis2.org wrote:

Hi Martin,

this is correct and a good observation.

If you look in the source code you can see that we have specified a JSON field name directly on the get method:

@JsonProperty( "organisationUnits" )

https://github.com/dhis2/dhis2-core/blob/master/dhis-2/dhis-api/src/main/java/org/hisp/dhis/organisationunit/OrganisationUnitGroup.java

This was done to improve on a bad naming choice (“members”) in the past and to expose a more sensible name in the API. This is then reflected in the schemas API as you observed. We hope to change the Java property name in the future but it requires a bit of refactoring.

You can get the name of collections as they are actually rendered in the API through the “collectionName” schema property in the mean time. You could say that we should have a dedicated consistent schema property for the “API field”, we could perhaps work on that.

best,

Lars

–
**Martin Van Aken - **Freelance Enthusiast Developer

Mobile : +32 486 899 652

Follow me on Twitter : @martinvanaken

Call me on Skype : vanakenm

Hang out with me : martin@joyouscoding.com

Contact me on LinkedIn : http://www.linkedin.com/in/martinvanaken

Company website : www.joyouscoding.com

On 6 January 2018 at 14:26, Martin Van Aken martin@joyouscoding.com wrote:

Hello!

I’m making a new DHIS2 App and so make use of the API through d2. I think I found an inconsistency between the schema as exposed under api/schemas and the real field returned.

Having access to the schema is very handy to directly know for example which field to show & how (as we have access to their property types).

There are similar situation for OU (organisationUnitGroups vs just “groups”) and probably other.

Is it something I’m missing or is that a mistake? If this is a bug, let me know if I can fill a PR (with some direction from the team).

Thanks,

Martin

–
**Martin Van Aken - **Freelance Enthusiast Developer

Mobile : +32 486 899 652

Follow me on Twitter : @martinvanaken

Call me on Skype : vanakenm

Hang out with me : martin@joyouscoding.com

Contact me on LinkedIn : http://www.linkedin.com/in/martinvanaken

Company website : www.joyouscoding.com

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

Lars Helge Øverland

Lead developer, DHIS 2

University of Oslo

Skype: larshelgeoverland

lars@dhis2.org

http://www.dhis2.org

–

**Martin Van Aken - **Freelance Enthusiast Developer

Mobile : +32 486 899 652

Follow me on Twitter : @martinvanaken

Call me on Skype : vanakenm

Hang out with me : martin@joyouscoding.com

Contact me on LinkedIn : http://www.linkedin.com/in/martinvanaken

Company website : www.joyouscoding.com