re: EMPIREDB-189 discuss

[Rainer Döbele <do...@esteam.de>]

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:news@eknet.org] 
to: dev@empire-db.apache.org
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: eike@eknet.org   https://eknet.org  pgp: 481161A0