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
>
>
>
>