ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick <ric...@gmail.com>
Subject Re: iBATIS 3.0 selectOne SessionException if no data found
Date Wed, 26 Aug 2009 17:07:25 GMT
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 <tgs@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-unsubscribe@ibatis.apache.org
> For additional commands, e-mail: user-java-help@ibatis.apache.org
>
>


-- 
Rick R

Mime
View raw message