Yes, I really mean a JSR, because I think it will need a large expert
analysis to not forget anything.
And also I do believe this solution could enhance development experience
so much if could be standardized.
Just like the a "beans validation framework", and "error management
framework".
IT, I'll try to make a small lib to capture original SQLRequest to get
the error code and error message, then encapsulate on a standard wrapper.
I don't think it would be harder than this, but a standardization would
benefits all the community, because every app that uses a database need
to treat error messages someday.
Well, I made my suggestion for a standardization (may be not a new JSR,
but an enhancement for a "JPA 2" version ;-) ) ... Anyway, I'll try my
solution and see what problems could arise from this.
Thanks,
Richter
Marina Vatkina escreveu:
> Hi Edson,
>
> Did you really mean a JSR? Or an issue tracker feature request?
>
> The problem is - the spec requires persistence provider to throw very
> specific
> exceptions (which are very generic on the other hand) to the client.
> Which
> means that even if there is a correct code that translates db-specific
> error code (I'm not that sure that they are all the same though) to a
> set of
> predefined exceptions, those exceptions will be wrapped into another ones
> to be spec compliant. At this moment, the error message is most probably
> prefixed with the provider-specific text, and there is no rule in place
> on whether it's required to add the original exception as the nested one
> (which is also true for SQLException -> Provider-smart-exception
> translation).
>
> thanks,
> -marina
>
> Edson Carlos Ericksson Richter wrote:
>> Thank you. I did suppose that.
>> IMHO, every (sql based with ACID support) database on the world has
>> some common exceptions thrown in response to events: pk violation,
>> unique violation, check constraint violation, fk violation, custom
>> errors (by ex: trigger based errors).
>> Later is thrown, for example, by MS SQL Server issuing a "raiserror"
>> inside a trigger.
>> Why not having TopLink capturing this as part of it's database
>> support, and throw a SQLException descendant categorized as above?
>> This really would easy database oriented apps.
>> Is necessary to open a JSR?
>>
>> Thanks,
>>
>> Edson Richter
>>
>>
>> Marina Vatkina escreveu:
>>
>>> Hi,
>>>
>>> This is a complicated one. Not only the spec doesn't prescribe
>>> on how to extract SQL exceptions, i.e. there is no guarantee
>>> that it's a nested exception, or the level at which it is nested,
>>> but the container can add more exceptions on top of the provider,
>>> if you try to parse it on the client side.
>>> And yes, if you want to guarantee the exact mapping between an
>>> error code and the text message, you need to do it yourself (and
>>> do it for all dbs that you plan to work with).
>>>
>>> thanks,
>>> -marina
>>>
>>> Edson Carlos Ericksson Richter wrote On 09/09/06 11:09,:
>>>
>>>
>>>> Hi!
>>>>
>>>> I'm creating a proof of concept for a first web app completely
>>>> based on JPA and Glassfish.
>>>> This app will relay heavy on CRUD operations, so first decision was
>>>> design database first or entity beans (and relay database creation
>>>> to persistence layer - Top Link, in this case). I choose create
>>>> entities. Until now, this was a wise choice.
>>>> Second decision is how many layers app will have, and what
>>>> technologies will be there. Decision was made to:
>>>>
>>>> * View: JSP
>>>> * Controller: Servlet
>>>> * Model: Entities and specialized beans when necessary
>>>> * Business logic: Singleton classes
>>>> * High level persistence: Singleton broker classes
>>>> * Low level persistence: TopLink essentials through annotations
>>>> * Database: undefined. During development, JavaDB. For deployment,
>>>> Oracle and MS SQL Server.
>>>>
>>>> In this architecture, all levels re-throw every exception to the
>>>> Controller, who register on the log and prepare message for
>>>> presentation (made by View layer).
>>>> The problem is: how could the Controller capture the error message
>>>> from persistence layer for treatment of, let's say, duplicate key?
>>>> TopLink capture database exceptions and transform them into common
>>>> "DuplicateKeyException"? Or I should deal with different error
>>>> codes from each database and do it myself?
>>>>
>>>> Thanks,
>>>>
>>>> Richter
>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>>>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>>>
>>>
>>>
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
>> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_glassfish.dev.java.net
> For additional commands, e-mail: users-help_at_glassfish.dev.java.net
>
>
>