While term “attributes” is used to refer to variables exposed in a Java class and the columns in a database table, I believe TRUNK-2939 is referring to the “attributes” tables in the OpenMRS data model. Using the om.rs/dm data model browser, you can see these tables as an example (that reminds me, now that Ref App 2.10 is released, I need to add it to the browser).
In brief, we have created some tables and corresponding Java classes in OpenMRS where we add “_attribute” to a domain object. The purpose is to allow local extensions to the data model without having to modify the shared (core) data model. It started when @dkayiwa noticed the extensibility of the EAV pattern in our obs table along with several requests from implementations for implementation specific adjustments to the data model (e.g., Tanzania wanted to record the “ten cell” for each person – a convention specific to that region for identifying clusters of homes). He thought, could we apply the extensibility of obs to our person object. So, we created a person_attribute table along with an person_attribute_type table to define custom “attributes” of person that would be an alternative to adding a new column to the person table (since not everyone wants or needs a “ten cell” attribute for person).
This approach of adding an
x_attribute table has been repeated for several other domain objects for the same purpose.
So, core OpenMRS knows that attributes exist and can use them (based on their attribute type definition), but core code should never refer to a specific OpenMRS attribute, since any attribute of a table needed by core should instead be added to the core data model directly.
This allows implementations to extend the model where needed and, when we see broad use of the same OpenMRS attributes, we can introduce them directly into the core model. This approach and a desire to align with HL7 FHIR are major drivers behind core data model decisions.