@Ramsey, yeah I had the feeling I might end up with gray hairs trying to
find that EO too so I am going with the index name.
@Chuck - I didn't have to get the table name to get an entity. I notice I
can get the EOAdaptorOperation that exposes the entity. Here is what I have
so far.
@Override
public boolean handleDatabaseException(EODatabaseContext
databaseContext, Throwable throwable) {
if(throwable instanceof EOGeneralAdaptorException) {
EOGeneralAdaptorException e =
(EOGeneralAdaptorException)throwable;
EOAdaptorOperation failedOp =
(EOAdaptorOperation)e.userInfo().objectForKey(EOAdaptorChannel.FailedAdaptorOperationKey);
if(failedOp != null && failedOp.exception() instanceof
JDBCAdaptorException) {
JDBCAdaptorException ae =
(JDBCAdaptorException)failedOp.exception();
//see oracle error codes
switch(ae.sqlException().getErrorCode()) {
case 1: //Violates unique constraint ORA-00001
Matcher m =
Pattern.compile("\\(.*(\\..+)\\)").matcher(ae.sqlException().getMessage());
if (m.find()) {
throw
ERXValidationFactory.defaultFactory().createException(null,
null, null, failedOp.entity().name() +
m.group(1));
}
}
}
}
return super.handleDatabaseException(databaseContext, throwable);
}
Question is, will there always be an EOAdaptorOperation that exposes the
entity taken from userInfo? "Coz this code is useless if it's not guaranteed
and will have to use your ERXEOAccessUtilities.entityUsingTable().
Amiel
On Wed, Jan 13, 2010 at 8:19 AM, Ramsey Lee Gurley <[email protected]> wrote:
> Hi Amiel,
>
> That's basically what I'm doing with Postgresql right now too. I managed
> to retrieve an EO if the operation is updating the EO instead of creating
> one. I cheated and used the editingContext for the database context from
> _databaseContextState().objectForKey("editingContext"). Even then, I was
> unable to use that context to retrieve the object if it is a new EO. Given
> Chuck's mention of deferred constraints, I could see how that might throw
> another wrench into the process. I was expecting to use the bindings from
> the statement that failed to figure out which EO to grab.
>
> Anyway, at this point, I've pretty much given up hope on retrieving the EO.
> I spent waaaay too long trying to find a cure for that problem. (^^) An
> index name is at least sufficient to return a somewhat informative message.
>
> Ramsey
>
> On Jan 12, 2010, at 1:26 AM, Amiel Montecillo wrote:
>
> > Hi Chuck,
> >
> > I'm not sure if I got you correctly (english is not my natural language).
> But this what I am doing:
> >
> > 1. Determine the unique constraint violation exception
> >
> > 2. Get the table and constraint name
> >
> > Next exception:SQL State:23000 -- error code: 1 -- msg: ORA-00001: unique
> constraint (WATCHLISTDEV.WATCHLISTUSER_CON_UEMAIL) violated
> >
> > 3. throw new ERXValidationException(constraintName, null, null);
> >
> > 4. In ValidationTemplate.strings:
> >
> > WATCHLISTDEV.WATCHLISTUSER_CON_UEMAIL = "This email address is already
> taken.";
> >
> > It works, but I am not sure this is the best way.
> >
> > Amiel
> >
> > On Tue, Jan 12, 2010 at 2:07 PM, Chuck Hill <[email protected]>
> wrote:
> > Hi Amiel,
> >
> > You can only get it if you are not using deferred constraints. If you
> are using deferred constraints, the exception is only thrown at the end of
> the transaction and EOF has no way of knowing which EO caused the error.
> The best solution that I have found is to parse out the table name and use
> that to infer the entity. If you are using single table inheritance, this
> is not perfect, but as all entities in the inheritance hierarchy will have
> to have the same constraint the error is probably also consistent. If you
> can get the entity name, you can then form a reasonable error message.
> >
> >
> > Chuck
> >
> >
> >
> > On Jan 11, 2010, at 9:56 PM, Amiel Montecillo wrote:
> >
> > Hi Everyone,
> >
> > Is it possible to get the failed EO instance when an unique constraint
> violation occurs? I have been digging in EOGeneralAdaptorException but I
> couldn't figure out how to get the instance of the EO that has failed.
> >
> > Rgds,
> > Amiel
> >
> > --
> > socket error: unable to connect to 127.0.0.1
> > _______________________________________________
> > Do not post admin requests to the list. They will be ignored.
> > Webobjects-dev mailing list ([email protected])
> > Help/Unsubscribe/Update your Subscription:
> >
> http://lists.apple.com/mailman/options/webobjects-dev/chill%40global-village.net
> >
> > This email sent to [email protected]
> >
> > --
> > Chuck Hill Senior Consultant / VP Development
> >
> > Practical WebObjects - for developers who want to increase their overall
> knowledge of WebObjects or who are trying to solve specific problems.
> > http://www.global-village.net/products/practical_webobjects
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> > --
> > socket error: unable to connect to 127.0.0.1
> > _______________________________________________
> > Do not post admin requests to the list. They will be ignored.
> > Webobjects-dev mailing list ([email protected])
> > Help/Unsubscribe/Update your Subscription:
> > http://lists.apple.com/mailman/options/webobjects-dev/rgurley%40mac.com
> >
> > This email sent to [email protected]
>
>
--
socket error: unable to connect to 127.0.0.1
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list ([email protected])
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
