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:[email protected]]
to: [email protected]
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
