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 protected]> 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).
> 
> Seems pretty good to me!  :-)
> 
> 
> 
> 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 <[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
> 
> -- 
> 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/webobjects%40avendasora.com
> 
> This email sent to [email protected]

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

Reply via email to