ibatis-user-java mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Debasish Dutta Roy" <debasish.dutta...@gmail.com>
Subject Re: locating errors in SqlMap
Date Wed, 19 Jul 2006 14:45:41 GMT
Agreed! There could always be more improvements.

For same resultsets and same column names and same bean properties like
situations, I think a good approach is to use qualified names. I mean use
the name spaces that you define your sql map files.  Then you will always
get to the particular culprit in the name space, rather than the total sql
map. iBATIS logs then will have nameSpace.methodName and you will know which
particular xml file has the problem.

On 7/19/06, Vadim Grinshpun <vadim@ll.mit.edu> wrote:
>
> Debashish,
> I can see where you are coming from, but there are some situations where
> iBATIS is not as well-behaved.
> Situations where iBATIS error messages are not very helpful include
> basic things like a typo in the XML(a missing quote, or close tag), in
> which case the parser goes completely berserk in its interpretation of
> the xml file. Also, if the same result map is re-used in multiple
> places, or you have identical column names in different tables (or
> property names in different beans), the error messages shown are not
> specific enough to identify the culprit easily.  Having a line number,
> or the name of the select statement, would be very helpful.
>
> I wish I could provide examples, but the system I work on is not
> connected to the net, and getting data off is a rather painful process.
> -Vadim
>
> PS for the record--I do have logging turned on, it is indeed a
> lifesaver; and I've been using iBATIS for a few months now, so I've
> learned to recognize many of the things that were confusing at the
> beginning)
>
>
> Debasish Dutta Roy wrote:
> > I would opt to disagree.
> > Following the suggestions would surely help. You can also put logs for
> > iBATIS. There are many email threads about that.
> >
> > I have made many minor to major mistakes in the sql-map files and have
> > been pointed quite well by iBATIS.
> >
> > E.g. I do get logs like this
> >
> > com.ibatis.common.jdbc.exception.NestedSQLException:
> > --- The error occurred in xml/Request.xml.
> > --- The error occurred while applying a parameter map.
> > --- Check the updateRequestNumber-InlineParameterMap.
> > --- Check the parameter mapping for the 'number' property.
> > --- Cause: java.sql.SQLException: Invalid column type
> > Caused by: java.sql.SQLException: Invalid column type
> >
> > OR,
> >
> > Caused by: com.ibatis.common.xml.NodeletException : Error parsing
> > XML.  Cause: com.ibatis.common.exception.NestedRuntimeException: Error
> > parsing XPath '/sqlMapConfig/sqlMap'.  Cause:
> > com.ibatis.common.xml.NodeletException: Error parsing XML.  Cause:
> > com.ibatis.common.exception.NestedRuntimeException : Error parsing
> > XPath '/sqlMap/select'.  Cause:
> > com.ibatis.sqlmap.client.SqlMapException: There is no result map named
> > Profile.get-PPI-select-values in this SqlMap.
> > Caused by:
> >
> > And I exactly know where to go. Also, get the source code in your path
> > and you can debug the source code also. That will surely help.
> >
> > Best Regards
> > Debasish
> >
> > On 7/18/06, *Ted Schrader* <tschrader@gmail.com
> > <mailto:tschrader@gmail.com>> wrote:
> >
> >     Hi Vadim,
> >
> >     I feel your pain in quietly cursing iBATIS' seemingly mystical error
> >     messages when I was first starting out.
> >
> >     I'm not aware of any way to make iBATIS' error mechanism more
> verbose.
> >     In practice, I do the following, along with your suggestion of
> >     commenting out parts of the map:
> >
> >     1.  Keep the SQL Map XML files concise.
> >     2.  Separate SQL Map XML files into logical units.
> >
> >     I reckon a good idea would be to start a catalog of various error
> >     messages on the wiki, or maybe even a full-blown debugging strategy
> >     section (I didn't see one after a quick perusal of the wiki today).
> >     Taking your example:
> >
> >     Error:
> >     "no readable property named FOO"
> >
> >     Problem:
> >     iBATIS cannot find the FOO property on the class specified in the
> >     result map.
> >
> >     Resolution (the usual suspects):
> >     Does the class have a FOO property?
> >     Does the class adhere to JavaBeans specifications?
> >     Is the result map element free of typos?
> >
> >     I suspect this could turn out to be an extremely helpful resource if
> >     maintained, but I personally lack the time to get this sort of thing
> >     started.  Any takers?
> >
> >     Ted
> >
> >     On 18/07/06, Vadim Grinshpun <vadim@ll.mit.edu
> >     <mailto:vadim@ll.mit.edu>> wrote:
> >     > Hi all,
> >     >
> >     > in a situation where iBATIS's parser throws an exception, is
> >     there a way
> >     > to tell which part of the sql map being parsed is actually the
> >     culprit?
> >     > The error shown in the exception is too vague, and doesn't point
> >     to a
> >     > particular file/line/xml element/whatnot. Specifically, I have a
> >     case of
> >     > a "no readable property named FOO", but the FOO in question is
> being
> >     > used in a number of places, a number of which have just been
> >     modified. I
> >     > could try to track it down by commenting out different parts of
> >     the map
> >     > to see which part(s) make the error go appear/go away, but I was
> >     hoping
> >     > there might be a more intelligent way to approach this.
> >     >
> >     > If there isn't a better way to do this currently, is it feasible
> >     to add
> >     > better error reporting facilities into the parser, and are there
> any
> >     > plans to do so?
> >     >
> >     > Thanks for any advice.
> >     > -Vadim
> >     >
> >
> >
>
>

Mime
View raw message