So our take-away here is to not do automagic but instead tell api users to put trimming/nulling into either their save methods or their setters?
Ben On Mon, Sep 12, 2011 at 5:24 PM, Darius Jazayeri <[email protected]>wrote: > 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] >> > > ------------------------------ > Click here to > unsubscribe<[email protected]?body=SIGNOFF%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]
