OpenMRS Platform 2.3.0-beta released for testing

Thanks very much for this report @mogoodrich!! :slight_smile:

This is likely because the data is already predetermined in the data set tested against.

I guess overriding the associated setters/getters as well could help solve this.

Yes @ruhanga it feel weird and wrong to be added new private variables for things like voided when they are already on BaseOpenMRSData… it looks like we did this just so we could do the mapping via Annotation instead of by mapping file? Would there be another way to go about this?

I’ve been able to reproduce the issue in a unit test that can be run against OpenMRS Core… I’ve reopened TRUNK-5492 and added the example there:

Also, digging a little deeper I’m not sure I love adding ā€œdummyā€ tables to the data model just to be able to support Hibernate annotations, for example:

   mysql> describe obs_unused_fields;
+--------------+----------+------+-----+---------+-------+
| Field        | Type     | Null | Key | Default | Extra |
+--------------+----------+------+-----+---------+-------+
| obs_id       | int(11)  | NO   | PRI | NULL    |       |
| changed_by   | int(11)  | YES  |     | NULL    |       |
| date_changed | datetime | YES  |     | NULL    |       |
+--------------+----------+------+-----+---------+-------+
3 rows in set (0.00 sec)

mysql> describe provider_unused_fields;
+-------------+------------+------+-----+---------+-------+
| Field       | Type       | Null | Key | Default | Extra |
+-------------+------------+------+-----+---------+-------+
| provider_id | int(11)    | NO   | PRI | NULL    |       |
| description | varchar(1) | YES  |     | NULL    |       |
+-------------+------------+------+-----+---------+-------+
2 rows in set (0.00 sec)

See for an explanation:

Sorry for weighing in on this so late in the process.

fyi @dkayiwa @mksd @wyclif @mseaton @burke

Agree. Creating tables like obs_unused_fields and provider_unused_fields is an ugly workaround that suggests we’re doing something wrong. For example, since Obs extends BaseChangeableOpenmrsData, then it should have changed_by and date_changed attributes… or it shouldn’t extend BaseChangeableOpenmrsData. Similarly, for Provider, either we add a provider.description attribute or Provider shouldn’t extend BaseCustomizeableMetadata (i.e., we need a version of metadata that doesn’t include a description).

It would be good to get some input from @wyclif.

I actually made some changes to datafilter module to be able to work with hbm files so the switch to annotations is not really necessary anymore. I will just revert back to xml.

2 Likes

I reverted the use of annotations for obs, providers and users

1 Like

How about Patient/Person?

@wyclif , thats great, but i still dont see any reason for reverting back to xml. Thats sounds to me like a regression not a progreesion.

Actually we would just work more harder to completely switch to annotations. To me the revert is unnecesarry unless some thing was breaking.

@ruhanga so when are we having the full release? Are we gonna miss out on releasing this year?

I hope that we can have the full release before this year closes.

The fix to this was made, and somehow I missed a notification. @mogoodrich, I hope that there are no more pressing issues in implementing the platform 2.3.x series except from TRUNK-5691? Could we have a full release, then any further fixes can get merged in maintenance versions?

cc: @burke, @jennifer, @herbert24, @christine

@ruhanga , Am also waiting on your full release , because we agreed that the ref app 2.10 should now run on platform 2.3 rather than 2.2.0.

1 Like

Hi dear all,

Sorry that this is coming in during the peaks of the current festive season, which may partly be the why we have no digressions on having a full platform 2.3.0 release at the moment. Nonetheless, all the items on this project’s management page have been addressed and the fixes & features successfully tested by community volunteers and at least two implementation (Mekom Solutions & PIH) I’d like to therefore go ahead to have this full release effected unless there are blocking issues to address before 31st December 2019 which is tomorrow Tuesday. Thanks

Kind regards

Nathan

cc: @burke, @dkayiwa, @mksd, @wyclif, @mogoodrich, @mozzy, @jennifer, @herbert24

1 Like

wel done @ruhanga ,@mozzy could this be of great use for the release of reference app??

1 Like

@ruhanga as per my comment above, the revert for annotations was not complete.

1 Like

Thanks @dkayiwa. I hope that we can be able to have these fixed by second half of January 2020 so we get the full platform version released out.

@mogoodrich, @wyclif any thoughts about the changes on Patient/Person and whether on not to revert them? Thanks.

:smiley: Glad to say that we now have https://uat-platform.openmrs.org for UAT testing of Platform! For more information, check https://wiki.openmrs.org/display/ISM/OpenMRS+environments.

See the talk thread here.

1 Like

Are Patient/Person the only things using annotations right now? I would go aI head and revert them as well for consistency.

Using annotations seems like a modern/easier way to handle mappings, but it did introduce some behavior changes (ie TRUNK-5492 and TRUNK-5691).

I also created a small clean-up ticket (but this isn’t necessary for the release):

Take care, Mark

1 Like

Some more good news here , UAT-SERVER for Platform is now available future testing is now easier.

@ruhanga @mozzy

1 Like

Thank you very much @permissionerror, @tendomart . This is great that we have a platform server to have the minor releases tested before a full release is made. :slight_smile: