EMPIREDB-189 discuss

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

On our development mailing list we are currently discussing how to deal with JIRA-Issue EMPIREDB-189.
https://issues.apache.org/jira/browse/EMPIREDB-189

Since not everone might be subscribed to the dev-list, here is the message again on the user list.
We'd be happy to receive your comments too.

Regards
Rainer


-----Original Message-----
from: Rainer Döbele [mailto:doebele@esteam.de] 
to: dev@empire-db.apache.org
re: EMPIREDB-189 discuss

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

Re: EMPIREDB-189 discuss

[Harald Kirsch <Ha...@raytion.com>]

Hi all,

to be honest, I did not read the javadoc properly but just went after 
the the signature and thought that a default value would prevent any 
problems.

Indeed I use it to retrieve an ID for a given items. If there is none 
available, I need to create the row for the item is question, along the 
lines of

int id = getSingleInt(...)
if (id<0) {
   id = createNewEntry(...)
}

With the current interface, I would need a try/catch instead of a simple 
"if". This obfuscates the code for a valid use case and degrades 
performance.

What is the use case where I need the current behavior for getSingleValue:

a) the row does not even exist -> exception
b) the row exists, but the requested column does not contain a value and 
only in this case I want to get the default value back.

I frankly cannot judge this because I do not have too much experience 
with databases in general.

If no good examples come forward for this use case, I would vote for 
option (2)

default value methods -> never throw
non-default methods -> throw or return null

A fourth option could be to adapt ideas from Scala and return a 
dedicated Tri-State object that helps to make the difference between the 
three cases

Tri<Integer> tri = getSingleInt(...)
if (tri.hasValue()) {
   id = tri.get();
} elseif (tri.hasRow()) {
   id = myDefaultValue;
} else {
   // not even the row is available
}

My use case would then look slightly different:
Tri<Integer> tri = getSingleInt(...)
if (tri.hasValue()) {
   id = tri.get();
} else {
   id = myDefaultValue();
}

In Scala the Tri would actually be an Iterable, so I would write
for(Integer id : getSingleInt(...)) {
   // end up here only if this single int was there
}

I know this would completely change the current interface :-(

Harald.


On 29.08.2013 20:02, Rainer Döbele wrote:
> On our development mailing list we are currently discussing how to deal with JIRA-Issue EMPIREDB-189.
> https://issues.apache.org/jira/browse/EMPIREDB-189
>
> Since not everone might be subscribed to the dev-list, here is the message again on the user list.
> We'd be happy to receive your comments too.
>
> Regards
> Rainer
>
>
> -----Original Message-----
> from: Rainer Döbele [mailto:doebele@esteam.de]
> to: dev@empire-db.apache.org
> re: EMPIREDB-189 discuss
>
> 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
>
>
>

-- 
Harald Kirsch
Raytion GmbH
Kaiser-Friedrich-Ring 74
40547 Duesseldorf
Fon +49-211-550266-0
Fax +49-211-550266-19
http://www.raytion.com