I agree with Burke here, I think that allowing people to store "" in a required field, and using that to represent "yes, but unknown" isn't right. You should store an explicit and recognizable unknown value, e.g. "Unknown". So for the guardian case, no guardian means do not store a row in the person_attribute table for the non-existent guardian. And an existent-but-unknown guardian would be stored as an attribute whose value is a pointer to an "Unknown Person" person.
Also, at a web UI level, the standard widgets don't distinguish between these things (i.e. if you have an attribute type whose datatype is "person", the out-of-the-box widget is just going to show a person chooser, not have an extra "click for unknown")... -Darius On Friday, September 23, 2011, Burke Mamlin wrote: > Roger, > > As you suggest, treating all empty strings as null will enforce that > required fields cannot be blank, since we won't be able to distinguish > between answered with an empty string from not answered at all. That said, > when is it "okay" to respond to a required question with nothing? Wouldn't > your example be better handled by recording the "Unknown" (in the case that > the orphan has a legal guardian who is currently unknown) instead of > treating unknown the same as if the field were skipped? And/or record "N/A" > when the field doesn't apply (in OpenMRS, we would probably just omit > storing an observation altogether if it didn't apply). > > -Burke > > On Fri, Sep 23, 2011 at 8:59 AM, Friedman, Roger (CDC/CGH/DGHA) (CTR) < > [email protected]> wrote: > > Darius –**** > > I believe I gave several examples during the earlier round of this > discussion. Here’s one – an orphan has a legal guardian, but the person > bringing the orphan to the clinic doesn’t know who, so the field is left > blank; a non-orphan does not have a legal guardian. So when it comes time > to report, you do something patient left join person_attribute where > attribute_type=”Legal Guardian” and format the nulls as “N/A” and print the > empty strings.**** > > I don’t think the automagic works with the new attribute paradigm. > Take a required attribute like National ID. The patient does have her card > with her when she comes to the clinic. Now we can’t save the patient info. > So I withdraw my tentative conclusion about properties. Is the > implementation of the minimum constraint still undecided? Let’s make sure > that’s well-understood before moving on to automagic.**** > > ** ** > > *From:* [email protected] [mailto:[email protected]] *On Behalf Of *Darius > Jazayeri > *Sent:* Thursday, September 22, 2011 4:36 PM > > *To:* [email protected] > *Subject:* Re: [OPENMRS-DEV] Empty string fields vs null fields**** > > ** ** > > https://tickets.openmrs.org/browse/TRUNK-2680**** > > On Thu, Sep 22, 2011 at 1:24 PM, Darius Jazayeri <[email protected]> > wrote:**** > > There is already AOP happening on every XyzService.saveXyz call. So we're > actually already paying the significant overhead. I think that > reflection+iterating over properties only on saveXyz methods is vanishingly > small additional overhead to the fact that every service call is AOPd.**** > > ** ** > > -Darius**** > > ** ** > > On Thu, Sep 22, 2011 at 12:51 PM, Burke Mamlin <[email protected]> > wrote:**** > > On Thu, Sep 22, 2011 at 3:03 PM, Darius Jazayeri <[email protected]> > wrote:**** > > So, does that mean you're fine with automagically changing empty String > properties of OpenmrsObjects to null before saving to the database?**** > > ** ** > > Yes. I love magic (I'm no muggle!)… as long as it's not going to add > several milliseconds or more to every API call. If doing it automagically > involves AOP or some other hook that is going to add (or contribute to) a > measurable performance hit, I would rather find a way to manage it > explicitly (via hibernate configuration, a custom hibernate type, and/or > code reviews).**** > > ** ** > > -Burke**** > > ** ** > > ------------------------------ > Click here to unsubscribe <javascript:_e({}, 'cvml', > '[email protected]?body\x3dSIGNOFF%20openmrs-devel-l');> from > OpenMRS Developers' mailing list _________________________________________ To unsubscribe from OpenMRS Developers' mailing list, send an e-mail to [email protected] with "SIGNOFF openmrs-devel-l" in the body (not the subject) of your e-mail. [mailto:[email protected]?body=SIGNOFF%20openmrs-devel-l]
