You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user-java@ibatis.apache.org by Kinjal Sonpal <fo...@gmail.com> on 2005/07/13 12:32:28 UTC

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

Re: queryForList not returning null

Posted by Larry Meadors <la...@gmail.com>.
You would prefer that after each call, you have to manually check for
list being null.

Seems like the same thing to me.

Larry

On 7/13/05, Kinjal Sonpal <fo...@gmail.com> wrote:
> 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.

Re: queryForList not returning null

Posted by Zarar Siddiqi <za...@utoronto.ca>.
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" <la...@gmail.com>
To: <us...@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 <za...@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" <fo...@gmail.com>
>> To: "iBatis mailing list" <us...@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
>> >
>>
>>
>>
> 



Re: queryForList not returning null

Posted by Larry Meadors <la...@gmail.com>.
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 <za...@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" <fo...@gmail.com>
> To: "iBatis mailing list" <us...@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
> >
> 
> 
>

Re: queryForList not returning null

Posted by Zarar Siddiqi <za...@utoronto.ca>.
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" <fo...@gmail.com>
To: "iBatis mailing list" <us...@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
> 



Re: queryForList not returning null

Posted by Kinjal Sonpal <fo...@gmail.com>.
On 7/13/05, Aladin <ib...@aladin.ca> wrote:
> Whatever happens, you'll have to check what the method returned.  May it
> be a boolean, String, NULL, or empty list.

Yeah, you are right, I was kind of just cross checking with others.
It's not documented either.

Thanks for the help.
Regards,
Kinjal

Re: queryForList not returning null

Posted by Aladin <ib...@aladin.ca>.
Hi Kinjal,

Whatever happens, you'll have to check what the method returned.  May it 
be a boolean, String, NULL, or empty list.

I personally don't see much difference between

if( (list = queryForList("..")) == null)
and
if( list.size > 0)

As a matter of fact, the second option is more intuitive.

Good Luck.

Aladin


Kinjal Sonpal wrote:
> 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
> 
> 
> .
>