On Jan 12, 2010, at 3:23 AM, Amiel Montecillo wrote: Yeah, I hope some freaky DBA won't change the constraint name.
If only EOF could spurt out the EO that caused the violation
The thing is, EOF doesn't know anything other than an error occurred. It doesn't know that it's a unique constraint violation, let alone which entity it was. You should be able to use a RegEx to parse the error message to get the table name (WATCHLISTDEV) and then go through the model and find which Entity that table is used by. If there are several entities that use it, you'd have to return an array of Entity names, or maybe just the superclass.
and that works with all supported DBs I'd be happier, but this will do for now.
The problem there is that all DBs have their own syntax for error messages.
Dave
Thanks again Chuck!
On Tue, Jan 12, 2010 at 3:33 PM, Chuck Hill <email@hidden> wrote:
On Jan 11, 2010, at 10:26 PM, 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.
I think that might be the best you can do with Wonder validation. Mike was adding something a while back, but I think you are doing it "right". Is does not feel very satisfactory, does it?
Chuck
On Tue, Jan 12, 2010 at 2:07 PM, Chuck Hill <chill@global-village.net> 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@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
--
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
--
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@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
|