Actually we've been treating the fact that when you save a patient, you get a bunch of person attributes with value=empty-string as a bug. (And it's a bug that occurs precisely because of this null != empty string behavior. I.e. >95% of the time the significance of that difference is that someone forgets to treat a submitted empty string as null in a controller.)
-Darius On Mon, Sep 12, 2011 at 5:56 AM, Friedman, Roger (CDC/CGH/DGHA) (CTR) < [email protected]> wrote: > One reason to keep the empty string rather than null is collating order; > null typically appears last, empty string first. > > Re what Ben says about person_attribute, I believe it is conventional > throughout OpenMRS not to make a record to store a null value (attributes, > obs, IDs), so if some required data is missing from an otherwise complete > set of data elements (the patient forgot his national ID card, the vaccine > manufacturer is missing from the mass campaign report, the patient forgot > his ID card from another facility), the empty string is needed as a > placeholder until that information becomes available. > > All of which is to agree with Burke that there are sometimes semantic > reasons to distinguish empty string from null. > > I would put this in the API in the setters, along with trimming/padding. > > -----Original Message----- > From: [email protected] [mailto:[email protected]] On Behalf Of Ben Wolfe > Sent: Monday, September 12, 2011 3:19 AM > To: [email protected] > Subject: Re: [OPENMRS-DEV] Empty string fields vs null fields > > If it was a runtime property switch that means that users/admins are > the ones making the decision. But it is not them but the developer > that should be deciding how to treat empty strings. > > I like the automatic solution, but I fear there might be places where > a column is not nullable but the user doesn't want a value there. > That would end up with us (or module developer) forcing a space into > the value to get around it, and that would definitely make things > worse. (I think person_attribute.value is like that now) > > So my vote would be to make it automagic by default but with the > annotation to remove that magic. > > And -1000 for switching to Oracle. Oh wait, Oracle already owns MySQL. > Crap. > > Ben > > On Sat, Sep 10, 2011 at 12:06 AM, Saptarshi Purkayastha > <[email protected]> wrote: > > +1 for it to be done through the API, without automagic, but probably a > > runtime-property to allow selecting automatic "" or null conversion > > -0 for switching to Oracle > > -1 for the annotation in code > > --- > > Regards, > > Saptarshi PURKAYASTHA > > > > My Tech Blog: http://sunnytalkstech.blogspot.com > > You Live by CHOICE, Not by CHANCE > > > > > > On 10 September 2011 02:00, Burke Mamlin <[email protected]> > wrote: > >> > >> I believe this should be done at the API level, in order to benefit > other > >> applications that use the API. I don't think it should be done > >> automagically (e.g., with an OpenmrsObjectSaveHandler) for two reasons: > (1) > >> there may be cases were an empty string and null are semantically > different > >> and (2) aspect-oriented changes like this are not without a cost (they > can > >> add up to real performance hits). > >> How about an annotation on the property like > >> @BlankValue(persist=NULL|BLANK)? . or maybe we should just switch to > Oracle. > >> ;-) > >> -Burke > >> On Fri, Sep 9, 2011 at 3:52 PM, Darius Jazayeri <[email protected]> > >> wrote: > >>> > >>> Hi All, > >>> The way that our webapp, our API, and the DB interact, we frequently > run > >>> into the case where we store empty strings in the database for values, > when > >>> they really should be null. > >>> For example if you save a Concept Source and leave the HL7 Code field > >>> blank, you save a row with concept_source.hl7_code = '' rather than > null. > >>> (Because the webapp submits an empty input, and we use spring MVC to > bind > >>> that to a bean property.) > >>> Two tickets that I looked at today are related to this (and there are > >>> certainly others): > >>> https://tickets.openmrs.org/browse/TRUNK-2516 > >>> https://tickets.openmrs.org/browse/TRUNK-2004 > >>> We should try to fix this problem in a general way. At first thought I > >>> can't come up with a case where we really want to save the empty string > in a > >>> database field rather than null. So some possible solutions are: > >>> > >>> (at the web level) use a custom PropertyEditor for the String class in > >>> all our Spring controllers, so that if you submit "" and bind that to a > >>> String property, it sets it to null. > >>> (at the API level) in OpenmrsObjectSaveHandler iterate over all String > >>> properties and if any of them are "" then set them to null. > >>> > >>> (The first would allow API consumers to explicitly set empty string > >>> properties on objects, while the second wouldn't.) > >>> Any thoughts on this? > > > > ________________________________ > > Click here to unsubscribe 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] > > _________________________________________ > > 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] > _________________________________________ 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]
