Re: Check / Force field uniqueness in EOF
Re: Check / Force field uniqueness in EOF
- Subject: Re: Check / Force field uniqueness in EOF
- From: Chuck Hill <email@hidden>
- Date: Thu, 26 Mar 2009 10:09:25 -0700
On Mar 26, 2009, at 7:49 AM, Dan Grec wrote:
Thanks for the replies all,
That makes a lot of sense.
I'm curious if anyone has developed a nice, detailed way of
displaying the error to the user.
Of course! :-)
I basically just catch the exception from ec().saveChanges() and
look at the exception.getMessage() to see if there is a particularly
named constraint in there.
If there is, I make a validation message something like "Entity
remote ID must be unique" and spit the user back to the same page.
The two shortcomings of this are that you can't tell the user what
they entered (ie "123 has already been used" )
and you can't tell which Entity was in conflict if the given screen
has a list of many EOs and the user modified more than one remote
IDs at a time.
Any thoughts?
First, handling this exception is database specific as there is no
standard / consistency in the error messages. So you need something
database specific to (a) determine if the exception is a constraint
violation and (b) get the name of the violated constraint. Then it is
a matter of using the other information in the exception and your
validation support to generate an appropriate message. Our ends up in
a strings file for each entity, e.g.
Department.uniqueDepartmentID.integrityConstraintViolation = "There is
already a Department with that ID.";
Which can also be parameterized as
Department.uniqueDepartmentID.integrityConstraintViolation = "There is
already a Department with ID <<id>>.";
Mike was going to put some of this in Wonder, I don't know if he did
or not.
You can also grab our frameworks from http://www.gvcsitemaker.com/chill/gvc_frameworks
The relevant code is in GVCEOFValidation and GVCEOFExtensions.
There is support for at least FrontBase and MS SQL Server, not sure
what else.
Chuck
On 26-Mar-09, at 1:01 AM, Ramon Havermans wrote:
Hi there,
Another advantage of letting the DB raise the exception is that it
is quicker. The db will just check all contraints on the db (the
unique one through an index) before inserting. If you do this
yourself you will do a fetch before the insert and than an insert
if its ok. Thats two actions for the db instead of one.
Kind regards,
Ramon
On Mar 25, 2009, at 8:51 PM, Chuck Hill wrote:
On Mar 25, 2009, at 12:46 PM, Dan Grec wrote:
Full of questions today....
I have an EO that has a field "RemoteSystemID" that must be
unique in the DB.
I have the constraint in the DB and that works well.
What I would like, is a way in EOF to detect non-uniqueness
without going to the db and relying on the SQL Exception.
Won't work, can't work, don't do it!
Currently, I have something like this:
@Override
public void validateForSave() throws
NSValidation.ValidationException {
validateRemoteSystemId();
super.validateForSave();
}
//check that no Categories have this same remoteSystemID
public void validateRemoteSystemId() {
NSArray<Category> categories =
SCEOFetcher.objectsMatchingKeyAndValue(editingContext(),
Category.class, _Category.REMOTE_SYSTEM_ID_KEY, remoteSystemId(),
EOFetcher.DBEC);
if (categories.count() > 1)
throw new NSValidation.ValidationException("Category
Remote System Id must be unique.", this, REMOTE_SYSTEM_ID_KEY);
}
This works really well if there is already one in the DB with a
value of say "123" and I try to add with with a value of "123".
This does not work if I try to add two at the same time with a
value of "567", it allows them both through.
Does anyone have a strategy to catch uniqueness at the EOF level?
Or, is it fine to just rely on the DB throwing an SQLException
and catch that after ec().saveChanges() ?
That is the only way to guarantee uniqueness. You can use the
code above to do a tentative validation (with the constraint still
in place on the DB), but the the DB has to be the ultimate
authority on what is and is not unique.
(I feel like letting that happen is bad, and might leave EOF in
an un-happy state - is there any chance of that?)
No. Failures in saveChanges at the database level are expected by
EOF and handled just fine.
Chuck
--
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
_______________________________________________
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
_______________________________________________
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
_______________________________________________
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