Mailing-List: contact user-java-help@ibatis.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user-java@ibatis.apache.org
Received-SPF: pass (asf.osuosl.org: local policy)
Message-ID: <008301c587b6$5988c3a0$53696480@sis.utoronto.ca>
From: "Zarar Siddiqi" <zarar.siddiqi@utoronto.ca>
To: <user-java@ibatis.apache.org>, <lmeadors@apache.org>
References: <370768f605071303326d5d0307@mail.gmail.com>
 <006901c587b2$11aa5070$53696480@sis.utoronto.ca>
 <a10a823c050713070471033a76@mail.gmail.com>
Subject: Re: queryForList not returning null
Date: Wed, 13 Jul 2005 10:22:50 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	format=flowed;
	charset="iso-8859-1";
	reply-type=original
Content-Transfer-Encoding: 7bit

One advantage as I see it of making such wrapper classes is that you get 
wrap SQLExceptions into your own custom Exception in just one place rather 
than having to do a try/catch block which wraps the exception in every 
method that accesses a database.  This alone was worth it for me.  It made 
code much neater and readable.  Same goes for logging.

As for cost of training and your other points about programmers not 
understanding an in-house API right off-the-bat, I think you're somewhat 
exaggerting the issue.  I'm not radically changing the API (or even 
modifying it really) at all, the methods can still have the same name (and 
even the same parameter names!) so I don't see how it can cost a company 
money.   Besides, if a programmer is so inclined to do so, they can always 
call something like Globals.getSqlMapClient() to do stuff manually.

Wrapping certain methods provided by SqlMapClient sure beats the hell out of 
doing log.isDebugEnabled(),  log.isInfoEnabled, try/catches in every method 
that calls a db.

Just my $.02 on the subject as a guy who's trying to get there. :-)

Zarar

----- Original Message ----- 
From: "Larry Meadors" <larry.meadors@gmail.com>
To: <user-java@ibatis.apache.org>
Sent: Wednesday, July 13, 2005 10:04 AM
Subject: Re: queryForList not returning null


> Where I work, we did that too, and it used to be one of our
> development standards. In fact, I was a leading proponent for the
> decision.
>
> However, we stopped when we realized that there are two choices you
> can make when you go down that path:
>
> 1) Mimic the existing API as closely as possible.
> 2) Change the API so that it suits your tastes better.
>
> Both when you look at them closely add very little value.
>
> In the first case, you add very little value, but gain the ability to
> hire help that can quickly learn the API, especially if they have used
> the wrapped API. the downside is that you create a bit more code to
> maintain.
>
> In the second case, you may improve the API, but you add more code and
> documentation to maintain, and it comes at the expense of training -
> you will never find a developer off-the-shelf who knows your API.
> Finding developers who know the SQLMap API is not difficult.
>
> In BOTH cases, it only ever matters if you change the API frequently,
> which i think everyone agrees is not a great idea.
>
> Just my $.02 on the subject as a guy who has been there, and done that. 
> :-)
>
> Larry
>
>
> On 7/13/05, Zarar Siddiqi <zarar.siddiqi@utoronto.ca> wrote:
>> What I do is that I have a base class (BaseDAOSqlMap) which encapsulates 
>> all
>> my data access.  In it are methods like getList(String,Object) which 
>> calls
>> queryForList which allows me to define custom behavior of what getList()
>> returns.   That way if the implementation for queryForList() changes (I 
>> know
>> its unlikely), I have to change my code in one place.  Just a thought.
>>
>> Zarar
>>
>>
>>
>> ----- Original Message -----
>> From: "Kinjal Sonpal" <forwardtokinjal@gmail.com>
>> To: "iBatis mailing list" <user-java@ibatis.apache.org>
>> Sent: Wednesday, July 13, 2005 6:32 AM
>> Subject: queryForList not returning null
>>
>>
>> > Dear All,
>> >
>> > Today while using queryForList method, I realised that if there are no
>> > records in the resultset, it returns an empty list unlike
>> > queryForObject (which returns null). Is it an undocumented feature or
>> > that's how it should have been?
>> >
>> > After each call, I have to manually check for the size of the list.
>> > Are there any known workarounds? Could not find much information over
>> > the internet or ibatis website/lists.
>> >
>> > Please advise.
>> >
>> > Thanks and regards,
>> > Kinjal
>> >
>>
>>
>>
>