Hi all, after long thoughts about this issue I have come to the following conclusion concering the querySingleValue() methods in DBDatabase:
IMO there is no reason why to distinguish between a result of NULL or an empty query i.e. in most cases the caller does not need to distinguish as both are a failed result. Hence there is no need to distinguish in the method's behavior. Then I decided that changing the methods' signature or create even more new overloads to the already (plenty) existing methods is not acceptable. However I think it is acceptable to change the behaviour of those methods that take a defaultValue parameter to return the default value in either case. For those methods without a default value, I would instead throw a QueryNoResult Exception in both cases, i.e. either if the query returned no result or the result was null as the result is undefined for such a case (and cannot be converted to a number). Only in the case of querySingleString() as a query result of NULL should return an empty String. The javadoc should explain the rest. I have already submitted the changes. I think it is minimally invasive and thus should not cause major compatibilty issues. Feel free to comment if you like. Regards Rainer --------------------------------------------------------------------------------------------------------------------------------- from: Eike Kettner [mailto:[email protected]] to: [email protected] re: Re: EMPIREDB-189 discuss Hi, I think, I would probably go in the `Optional` direction as Francis explained. I would create a class that encodes all the possible cases that can come out of a call to `querySingelInt` and other such methods. The result object could have similiar features like the `Optional` or `Try` class from scala, maybe even more specific to this use case. my 2 cents... Kind regards Eike On [Thu, 29.08.2013 10:06], Rainer Döbele wrote: > Hi everyone, > > > > I have some problems with EMPIREDB-189 as I am not sure what to do. > > > > In DBDatabase we have serveral overloads for querySingleValue, > querySingleInt, querySingleLong etc. which all return a scalar value. > > Some of those overloads take a parameter for a default value like e.g. > > > > int querySingleInt(DBCommand cmd, int defaultValue, Connection conn); > > > > Now the problem is, that the query faces two possible cases that we must deal > with: > > 1. The result of the query is null (or anything but a number) 2. The > query has no result at all, i.e. no row was returned > > > > For case 1 the defaultValue is correctly returned. > > For case 2 we throw a QueryNoResultException as described in the JavaDoc. > > So basically everything works as designed. > > > > However as Harald Kirsch reported, it might be desirable to have the > defaultValue returned for both cases instead of an exception in case 2. > > On the other hand this has the following drawbacks: > > 1. Those methods without a defaultValue would still throw and > exception for case 2 and return null (or 0) for case 1, thus making > the be behavior of the different overloads inconsistent 2. There is no > way to distinguish between the two cases > > > > Basically we have IMO three options: > > 1. Leave everything as it is > > 2. Change only the behavior of the overloads with a defaultValue not > to throw an exception but to return the defaultValue instead 3. Change > the behavior of all querySingleValue methods not throw an exception > and instead return the defaultValue or null (or 0 or "") > > > > One argument for changing the behavior is, that in many cases these methods > are used for finding out whether a database record exists or not and an > exception is not desired. > > > > What's your opinion? > > > > Regards > > Rainer > > > -- email: [email protected] https://eknet.org pgp: 481161A0
