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