[
https://issues.apache.org/jira/browse/OPENJPA-1450?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12794875#action_12794875
]
Xiaoqin Feng commented on OPENJPA-1450:
---------------------------------------
I am on vacation from 12/20/2009 Â to 12/26/2009.
If you have any question on deployment and JEE bugs, please contact Saurabh
Arora or my manager Maruthi Nuthikattu.
For emergency, contact me at 925-209-5517.
> Enhance SQLException thrown from "JDBCStoreManager.load()" to show entity and
> field info
> ----------------------------------------------------------------------------------------
>
> Key: OPENJPA-1450
> URL: https://issues.apache.org/jira/browse/OPENJPA-1450
> Project: OpenJPA
> Issue Type: Improvement
> Components: jdbc
> Affects Versions: 1.2.1
> Reporter: David M. Karr
> Priority: Minor
>
> If I define my mapped instance variable to be of a type incompatible with how
> its stored in the database, I get a "SQLException: Fail to convert to
> internal representation" error. The error in the log says nothing about what
> entity and field this is in reference to. This is ok if I test very often, so
> it's likely that the last entity and/or field I added is the one with the
> problem, but if the realized relationships in my actual database data won't
> let me map an instance of that row until I manage to follow a path that loads
> an instance of that entity, then when I finally get the exception I'll have
> no clue what entity and field it is referring to.
> This is what happened to me. In order to find the problem, I had to use my
> debugger skills. I walked up the call stack until the point where the
> exception was first caught. I found that in "JDBCStoreManager.load()". I set
> a breakpoint in here right after it obtained the "ClassMapping" object, which
> has the entity class in it. By watching the printout of the ClassMapping
> object and noting whether continuing hit the exception, I finally found the
> entity that had the problem. Once I found that, I inspected the fields and
> found the problem.
> I wouldn't have had to follow this complicated debugging strategy if the
> catch clause in this method:
> } catch (SQLException se) {
> throw SQLExceptions.getStore(se, _dict);
> }
> incorporated some information about the "ClassMapping" object this method was
> processing when the exception occurred. This object holds the entity class
> and other information.
> I'm sure there are numerous other places where exception info could be
> enhanced with useful information. This is only place.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
