Attachments: Recognizable valueComplex structure, suggestions?

Hi all,

Back in the days when designing Attachments (formerly known as VDUI) we needed to make sure that complex obs saved through it could be recognized. This is because their value complex field would contain Attachments-specific metadata allowing for a maximum flexibility when implementing the backend handlers behind the scenes. In particular through providing an “instructions” metadata to direct the behaviour of the handler(s).

Here is an example value complex’s value:

m3ks | instructions.default | image/png | my_uploaded_image.png

A “unique” prefix was used In order to recognize the value complex as one belonging specifically to Attachments. And here it is:

m3ks |

Obviously we kept things short because the value_complex column is only 255 chars. So we needed something at the same time short and unique enough. I know, I could have counted the pipes.

The question is: is the current situation good enough? I would like to review this - not so amazing - design choice and get some ideas as to how this could be done better. Or perhaps the current situation is good enough and we’ll leave it at that.

P.S. The prefix was loosely built on our org’s name acronym. I wasn’t particularly inspired that day. *sigh*

Cc @gogochicken @dkayiwa @mogoodrich @ssmusoke @wyclif

@mksd, Is this an extension of what is described here? https://github.com/openmrs/openmrs-core/blob/master/api/src/main/java/org/openmrs/Obs.java#L877-L882

cc @burke

Yes exactly, it extends this logic allowing to provide more metadata in the value complex field (such as those “instructions”).