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]
