FWIW we're already paying the AOP overhead cost, since we already have an OpenmrsObjectSaveHandler called on every save. (It currently just sets a UUID if none is assigned.)
Since Oracle treats null and '' as identical, that suggests to me that allowing OpenMRS developers to make that distinction is a mistake. And certainly it will make the app behave incorrectly in Oracle. So I'd still prefer to automagically convert empty strings to null, or at least make it opt-out rather than opt-in. E.g. a non-annotated String property is treated as @BlankValue(persist=NULL). -Darius On Fri, Sep 9, 2011 at 1:30 PM, 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 <http://maml.in/nsmnbB>. ;-) > > -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<[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]
