On 15 June 2012 23:46, Vadim Zeitlin <[email protected]> wrote: > Hello again, > > Currently if a select statement results in a null value and no indicator > is defined for the corresponding output parameter, a "Null value fetched > and no indicator defined." exception is thrown. I like this very much as it > doesn't allow you to simply ignore nulls while still letting you to handle > them easily just by providing an indicator. > > However for some reason the same logic is not used for truncations. If > either output or input parameter is truncated (the latter happens in > insert/update instead of select), this is recorded in the associated > indicator, if any, but if there is no indicator the truncation is silently > ignored. > > I wonder if this is really correct. It is inconsistent with null handling > and also dangerous (as half an hour spent on tracking a bug due to not > noticing that a truncation happened in my code attests). Shouldn't an > exception be thrown if a value without an indicator is truncated? > > This would clearly be backwards incompatible as previously working code in > which truncations occurred would now start throwing exception but hopefully > the reason for this change in behaviour shouldn't be difficult to find so > maybe it's still worth doing? > > What do you think?
Vadim, (Sorry for the very long delay, apparently I've missed lots of the list posts.) I second Stephen's opinion, it sounds interesting. I reckon, it could be added in SOCI 4.0.0 or later. Feel free to add it to https://github.com/SOCI/soci/wiki/Roadmap so it's not missed. Best regards, -- Mateusz Loskot, http://mateusz.loskot.net ------------------------------------------------------------------------------ Everyone hates slow websites. So do we. Make your web apps faster with AppDynamics Download AppDynamics Lite for free today: http://p.sf.net/sfu/appdyn_d2d_jan _______________________________________________ soci-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/soci-users
