Rick's suggestion is correct. That was the idea.
Honestly, we don't have to throw the exception, but it is a good in practice
IMHO...
But you all tell me, do you really want to return null?
Clinton
On Wed, Aug 26, 2009 at 11:07 AM, Rick <ric...@gmail.com> wrote:
> Maybe a bit of a hack but ...
>
> public interface UserMapper {
> public List<Long> getUserIds(String email);
> }
>
> Keep the dao method the same...
>
> public long getUserId(String email) {
>
> but just do a quick check in there on the size of the List returned, and do
> what you want with it (throw you own exception if over size 1?)
>
> and then just always return list.get(0)
>
>
> On Wed, Aug 26, 2009 at 11:21 AM, Thomas G. Schuessler <t...@arasoft.de>wrote:
>
>>
>> In my MySQL db, I have a table 'users' with (amongst others) these
>>> fields:
>>>
>>> `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
>>> `email` varchar(120) NOT NULL,
>>>
>>> In UserMapper.java I have the following method
>>>
>>> public interface UserMapper {
>>> public long getUserId(String email);
>>> }
>>>
>>> In UserMapper.xml I have this:
>>>
>>> <select id="getUserId" parameterType="string" resultType="long">
>>> SELECT id FROM users WHERE email = #{email}
>>> </select>
>>>
>>> My DAO client code looks like this
>>>
>>> public long getUserId(String email) throws SQLException {
>>> SqlSession session = sqlSessionFactory.openSession(true);
>>> try {
>>> UserMapper mapper = session.getMapper(UserMapper.class);
>>> long userId = mapper.getUserId(email.toLowerCase());
>>> return userId;
>>> } catch (SessionException sex) {
>>> throw new SQLException("No data found.", "02000");
>>> } finally {
>>> session.close();
>>> }
>>> }
>>>
>>> What I am unhappy about is that in order to differentiate between the "no
>>> data found" situation and other cases, I would have to check the
>>> SessionException for the string "Expected one result to be returned by
>>> selectOne(), but found: 0".
>>> This is somehow unsatisfactory (at least to me) since I do not like to
>>> trust that string to never change...
>>>
>>> Is there another way to deal with the situation (without an additional
>>> SELECT COUNT...)? Maybe I have not found the optimal way to solve the issue?
>>> Otherwise, I´d like either a specific exception for this (and similar)
>>> cases, or a field with an error code in SessionException.
>>>
>>> Thank you for any input on this,
>>> Thomas
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: user-java-unsubscr...@ibatis.apache.org
>> For additional commands, e-mail: user-java-h...@ibatis.apache.org
>>
>>
>
>
> --
> Rick R
>
